Agreed. Here's what I see today:

Does converting IPs to regions and using them for caching work here? (to increase the cache hit rate)

🤔 that's an interesting idea. We could maybe convert it to coordinates, and then round it off to n (111km), or n.n (11km). 11km may still be too many cache misses, but 111km doesn't feel like it's granular enough. That's almost a 2 hour drive when using myself as a test.

Another thing we could try is what the Events Widget does, which is round off the last octet of the IP, so that it's just the class C address (e.g., 60.50.40.0). I'm guessing that also won't generate enough cache hits, though.

Maybe it'd be best to fetch the events via a REST request, so that it doesn't block the TTFB. That way we don't have to worry as much about caching 🤔

@fcoveram, can you create a design for this? I'm guessing it'll be similar to the Events Widget in Core, so we'd want a Select Location button that toggles an input field.

@StevenDufresne had a good idea, that this might not need a Select Location button. Instead we could just show the geolocated events, and if the visitor wants to see something different they can use the search/filters. Those don't exist in Core, but we can take advantage of them here.

Instead of the select button, we could have a chip for the geolocated city, with an x that someone can click on to remove it.

Thinking something like this:

On	Off

I like the idea. I can polish Steve's idea this week 👌

Thanks!

Here is an idea I have been iterating

The feature is inside the "Country" filter, now renamed as "Location", and it appears as a first option showing the location name and the radio area. Once clicking on it, the search results page shows the results filtered as now.

I wonder how we can bring the location name as, afaik, it depends on the browser settings, and converting the distance unit for different metric systems (kilometers, miles, etc).

That sounds good 👍🏻

I'd recommend leaving off the distance, because the Events API has different ranges for different event types. Folks are willing to go farther to attend a WordCamp than a meetup, so we use 100km for meetups, and 400km for WordCamps.

@StevenDufresne and I were talking more about the problem of not having enough events displayed, and came up with the idea of showing both local and global events at the same time. One way to do that would be to have a section for each, something like:

Showing 10 events in the homepage was intentional to keep the page slightly short and give space for other sections. And since events are the main content, the "Browse events" button and the link in local nav reinforce the navigation to land on the "Upcoming events" page where currently there are many items. I disagree that the amount of events displayed is a problem.

I also understand that we plan to include more types of events in the future, so "Upcoming events" would be even longer.

I do like the idea of featuring global events, but it seems that fits better with the next phase of implementation, where more rich-content events are also included. What do you think of addressing this idea later?

I was thinking we'd still keep it to 10 events or less, but they'd be spread across the two sections. I don't have a strong opinion about addressing that now vs in the next phase. What do you think @StevenDufresne ?

@fcoveram Thinking about this iteration, I'm not certain that updating the country to be location and adding the cue that we've geolocated in that dropdown would be expected or obvious to our users. It makes the "location" dropdown unpredictable because it will show my location first and then a list of countries. It wouldn't be clear to me what is included in the list. Are they countries? Regions? Cities?

To elaborate on @iandunn's comment about our conversation, which wasn't specific to the details of your proposed design, is that we don't have many events for the rest of the world.

Here is how the conversation went:

• We won't have many events for non-North American/European users
  • Okay, we can merge global (flagship and online) and local events together,
    • It's more likely for those users that 9 events are global and 1 is local
      • Because we include the date, the events are sorted chronologically
      • The local event could be at the bottom of the list and easily missed
        • Should we not sort chronologically or have a separate visual indicator to bubble up the local event?
        • Maybe we should break them into 2 lists?

I see your point, and I like the idea of surfacing events out of the northern hemisphere to boost a more equitable overview.

With that approach in mind, plus the map in the top area, I'm drawn to have the following structure:

• Cover area with map, where most pins will be in North America/Europe.
• "Featured events" section showing regional WordCamps and other key events.
• "Nearby events" section listing the closest events in a table where the "See all events" button is placed at the end.

The nearby section would replace the current upcoming events yet it keeps the search input, filters, and "see all events" button to redirect users to the "Upcoming events" page. This change means showing different content depending on your location, but as you both discussed, it addresses the geographical difference. My only doubt with this proposal is its compatibility with the browser's location permission, like the example below.

What do you think of this?

When we built the Events Widget in Core, we decided to use IP geolocation rather than the browser. That was in order to avoid having to interrupt the user w/ that prompt. I assumed that we'd use the same approach here, what do you think about that?