Every now and then you need a project that can challenge you where solutions won’t be so straightforward, and you need to be willing to fail in trials a few times before figuring out what will work best. While this project did not succeed in what it initially set out to do I felt it important to include it in my list of projects as a retrospective of how best to handle when things just don’t work out ideally and how to still find a way to serve a client with something useful in the long run.
The biggest engineering hurdle we had was in trying to determine how best to add some very specific functionality requests into the website while still keeping the build under budget (which largely meant no custom development expenses and relying on themes and pre-built plugins). This also ended up being our Achilles’ Heel.
Rugged Races organizes several different categories of athletic events across the country in partnership with local news organizations or their agency partners. They already had a public-facing website and a team of developers managing unique fronts for every individual race. Our job was not to replace any of that but rather to make a site which would attract third party sponsors interested in supporting a race in their local areas. Our point of contact had so far just been directing potential sponsors to a custom Google Map he had created which had toggle-able layers for race event categories and such, but it wasn’t pretty and was cumbersome to update and maintain. Our challenge was to find a better way.
View Their Old Website
The events list needed to be searchable and filterable in a few different ways. There needed to be a calendar view which would show that there were always events happening all across the country (something his current option lacked). A full calendar meant a sponsor had lots of opportunities for exposure. There also needed to be a map component to demonstrate that events were from coast to coast and everywhere between. And both of these needed to be filterable by event type (running, cycling, triathlons, obstacle courses), by distance (such as 5K, 10K, full marathons, etc.), and of course by dates and location. He had a searchable map already through Google, but not the calendar or having the pieces work together.
Our first solution was to try the ever-popular Event Calendar Pro by Modern Tribe. We’d used it on numerous builds and during discovery we setup a single page that had nearly all of the functionality we needed. However, we ran into an issue with the fact that the filtering toolbar (an additional add-on we’d purchased) would only appear on the main event calendar page and could not be added to additional sub-pages. There was no shortcode or “portable” version that could be added to events in other content pages. Since we planned to have pages for every event series and category, and include the calendar and map on each page, this would not work and was too limiting. Modern Tribe also didn’t have an ETA on when their plugin would have such options.
Next, we tried the EventOn plugin which at first was extremely promising. It was aesthetically pleasing featuring Material Design styled components (fitting trends at the time) and several other cosmetic options, and there were add-ons that could facilitate nearly everything we needed (including an add-on for a filter bar and an add-on for interactive maps).
However, we ran into two primary problems with EventOn. The first was that the client simply did not like the cosmetics. We tested various themes, went through each of the built-in customization tweaks, and even implemented custom CSS and jQuery DOM manipulation to try and get it closer to what the client had in mind, but there were always limitations and it became clear that we were already venturing too far out of scope and experimenting with custom development (which would therefore put us over budget rapidly if we continued down that road). This was a tough hurdle to get over and illustrates that no matter our own thoughts on design and cosmetics it’s always subjective and at the end of the day it’s the client’s site, not ours. We made concessions here because, no matter the limitations on cosmetics, it was always at least an improvement over the old Google maps they had been using.
The second hurdle with EventOn was that it wasn’t always immediately clear that a feature which we wanted might have its functionality in yet another add-on that we hadn’t bought. The map and list view were each separate purchases from the calendar view for one example, but also being able to import events from spreadsheet, being able to allow visitors to export events to their chosen calendar program, and the ability to do certain kinds of filtering also required additional plugins. That wouldn’t be too big of a concern since it’s the chief functionality of the website and all a part of the same ecosystem (so “plugin bloat” wasn’t a huge concern), but there were unexpected limitations as well.
For example, there was no on-the-fly filtering on the map view where checking or unchecking certain filters wouldn’t refresh the map’s pushpins. It required a user to select filters and then resubmit the search each time. Since our client was spoiled on how smoothly turning filters on/off worked on Google Maps, and since our communication with EventOn’s support ended with “it’s simply not a supported feature at this time”, it ended up being a dealbreaker for our client even more so than not liking the appearance.
At this stage, and after auditing a dozen more event and map based plugins, we had to have a tough conversation. Not saying “no”, but rather saying “yes, but here’s how”. There simply wasn’t an off-the-shelf, pre-built solution that could check all the boxes for our client. We could take either Event Calendar Pro or EventOn as a starting point and extend its functionality by building our own complementary custom plugin, but that would be an additional cost. We could do it, but it was a matter of the budget for the project.
Though we’d gotten closest with EventOn the client made the decision that adding a set of instructions to the page to get around the plugin’s search filter limitations just wasn’t a good look and made it feel clunky. The decision was made to simply build a set of easy-to-manage content pages that would house some different Google Maps as he was already familiar with managing those.
Our project scope changed from setting up functionality to instead setting him up to be able to quickly build and edit content pages with flexibility on the design and plenty of options for arranging things. Then we just had a cosmetic “wish list” of things like adding a video looping in the header, easy to manage photo galleries, and some easy-to-insert UI components such as buttons and calls-to-action. WordPress’s Gutenberg made a solid backbone, and a few block plugins like Kadence Pro filled in the gaps. I also put together some custom documentation with screenshots and saved various reusable custom blocks in the site’s editor to make any content endeavors easier for the client to self-manage.
