A Requiem for Spotlight
When I first began my position with the high-ed communication & marketing unit I call home our “web team” juggled a small handful of notable project types. The most important at the time was the projects we referred to as digital media experiences, or "DME"s. Notably so important the skills required for their authorship were specifically part of my job description and the development of one was part of my interview process. In essence the idea of a DME was a media-rich, story-driven single page website, inspired by the New York Times’ “Snow Fall: The Avalanche at Tunnel Creek”. In practice each DME was built in mostly anything that could sit by itself in a folder on a server. They were built differently each time, free from the tyranny of any kind of rigidly templated CMS. The content and media that composed them was culled from upcoming stories produced for the College’s magazine, but the site that composed the DME itself was built by a single developer under supervision of a combination of producers (like a writer or photographer). DMEs served many purposes but the silent driving purpose for the entirety of this concept, the same that drives many many offices positioned like mine, was to elicit jealousy in peer institutions.
Sadly, totally unpredictably, the labor required to develop these projects from scratch each time was not sustainable. Not only that, while existing DMEs managed to survive an impressive amount of time without maintenance they could not exist in such a state indefinitely. Once they started to reach a certain age their more impressive and interactive features began to fail noticeably. Decisions had to be made and time had to be weighed. Ultimately they were pulled offline en-masse as the increasing time crunch in that particular era meant we could not address even a small amount of maintenance projects, let alone maintenance projects we never budgeted for. So with little fanfare except for a bit of quiet migration all DMEs were made gone. Ideas always come around again.
After a particularly intensive stretch of WordPress work we were ready to revisit the DME concept. The utter luck at the timing of this moment felt to me like something akin to divine provenance. I had been anticipating we’d see the DME concept again and had been researching techniques to facilitate their authorship, not only were static site generators in vogue at this moment but their popularity was shaping the technologies used to build the web, and a perfectly customizable static site generator called Eleventy was making a name for itself. The second iteration of the DME was christened “Spotlight”, a place to shine a light on diverse narratives and important initiatives making a difference in the world. I constructed an eleventy-based system, pre Eleventy 1.0, with useful but minimally restrictive templating and extensive asset pipelines. I had to upload the project manually with each update, we weren’t interested in spending on specialized hosting that automated the process like Netlify, but luckily my institution has a classic 90’s-era hosting system available to the entirety of campus which worked out fine. Stories were constructed specifically for use as spotlights this time, as opposed to using them first as print stories and adapting them to the web later. This meant a few things. Visual media was able to be collected as expected needs changed, in the case where we had availability at least. The story itself was concepted to be more expansive, and to include supplementary material, as the restriction of the printed page and it’s word count was not explicitly a factor. Lastly, the storytelling and the features of each spotlight could be shaped in such a way as to hopefully complement each other.
In many ways Spotlight was an admirable success, notably we achieved a kind of reach and longevity my office had always desired but often found itself falling short of. Both Spotlight projects are still public at the time of this posting: Data is Life and Mind Control Prosthesis. Both found their construction via a truly collaborative and multi-disciplinary effort that ranged across the campus. Both receive notable attention and traffic to this day, despite having not received any marketing effort for years. Especially in the case of Mind Control Prosthesis, which still gathers participants interested in how the research can benefit them. Both remain browse-able and feature complete with almost no maintenance years after their launch. (I think there was some awards attached to them?) In almost every way Spotlight was a canonical example of the kind of project my office saw out in the world and very much desired to produce for our campus and for ourselves.
However in some critical ways it was, for some, a miserable experience. So miserable people openly scoff when the word “spotlight” is uttered in the office and, while no definitive statement has been made by leadership, my office chooses to no longer produce them. From my perspective, there are two reasons this happened.
- Each spotlight was meant to debut with the publishing of the corresponding research it was written about. The research was always months, sometimes weeks away from being published, and this state persisted for almost two years. In both cases. I suppose you might say we were naive. You might also say the faculty could’ve been better about estimating their work. Either way, both projects felt like they were constantly on a rubber-band of a timeline. People found that frustrating, especially those who had rarely ventured outside the public sector.
- Spotlight had been envisioned as deeply collaborative and cross-disciplinary. For the office that translated to large teams and a need for consensus. This did not work. There were far too many cooks in the kitchen, and sometimes they were working at cross-purposes. It took weeks, maybe months, to convince everyone the concept of Spotlight was a good idea. It was much different from how we had operated up to this point. We were well into production of the first before the team reached a collective understanding of what Spotlight actually was in functional terms. Decisions had to be constantly justified and any utterance of the word “no” required an expansive explanation, especially for technical restrictions. This was entirely exasperated by the fact, as I had noted earlier, timelines were being drawn out past our expectations over and over.
As the only person on the team who had built both DMEs and Spotlight my perspective is somewhat skewed. The experience of building DMEs felt torturous for a developer and somewhat less intensive for others. In a fascinating turn of irony, the frustration that ended Spotlight was also present in the DME process. Only instead of being spread out across the team it was centered with the developer, as the person responsible for presenting most of the decisions but not making them. In contrast Spotlight was much more enjoyable for me to work on. Eleventy was a dream to work with, providing enough structure and then getting out of the way. We could build with some assurance of sustainability, longevity, and ease of customization while keeping everything wrapped up in a convenient repo. We were building things that could withstand the test of time and we were building them well.
Some time after the last spotlight we started another intensive round of WordPress work (2020-ish) to bring our ecosystem into the Gutenberg-era. In doing so we found the flexibility of WordPress’ custom HTML block to be very useful in the right hands, used thoughtfully in a well-coded theme. Useful and reliable enough that it became the cornerstone of what we refer to as “Features”. Which are important stories where we expend extra careful effort to create custom layouts and story elements via the custom HTML block and creative use of Wordpress’ capabilities.
Unknowingly, by supporting the creation of Features I am sure I have ended Spotlight. When I built the technologies of Spotlight I optimized for flexibility and to reduce the need to say “no” because of the restrictions of a templated CMS. This is what I was asked to do, but it was not what was needed. When I built our WordPress ecosystem I made a bet about the future. That one of the best things we could do was closely support WordPress’ features as they were released and the rhythm of WordPress’ updates would eventually provide us the tools we needed. This proved to be a good bet, and the result has provided us with a ecosystem that allows for some useful, flexible, and isolated customization via the gate of technical skill. Ultimately his means we have returned to an era where these projects limit the scope of possible options and therefore streamline the decision process of their creation. This is what was needed. Creating a system which enforced a workflow that by necessity encourages decisions to be made by smaller pools of decision-makers, encourages that decisions be made closer to the people who are doing the work directly, and is optimized for time spent was what was needed. Even at the sacrifice of features.
Will we see Spotlight revisited? Maybe. Ideas always come around again, but I think the era of Spotlight has ended.
I will note I was certainly not doing this alone. There were other positions in the office with large technical components to their jobs that allowed us to support each other as best we could and juggle this labor. At the slim chance they are reading: thank you all. ↩︎
Though, beware anyone who says to you with a confident gravity “it will be different this time” without actually changing anything from last time. These are not people whose experience can be trusted. ↩︎
One of my tricks to keep myself knowledgeable when it comes to technologies of this type is to use them for personal projects. Which is why this site has always been built in Eleventy. On the flip-side, you can also burn yourself out on a technology by doing that. Which is why this site isn’t built in WordPress. ↩︎
You can read more about that via Snowfalling 11ty, though the techniques therein have not aged well. ↩︎
AFS, SFTP, etc. ↩︎
The more academic among you may say, “Ah, but Josh this is the nature of academic research.” Sure. But there’s a difference between doing research and being skilled at delivering research. ↩︎
Many of these discussions stemmed from the fact there was no budget allocated for these projects. For example: people wanted video features like they were used to experiencing on YouTube but didn’t want to actually use YouTube to host video because they were unhappy with YouTube’s intrusive branding. We did not have the resources to acquire streaming media hardware or a service to provide those features. The entire discussion was moot, we had to use YouTube because it was free or forego use of any notably large video files. ↩︎
Timelines were around three weeks. You had to develop features to the stage where they were mostly completed so you could show them to get the go-ahead to know whether or not you should spend time developing them. The work it took to make guesses about what individuals wanted to see and tease out consensus to develop them was utterly inappropriate on the average timeline. If someone didn’t like what they saw you usually had to go back to the drawing board. ↩︎
I was, again, not doing this alone. At the slightly more likely, but only slightly, chance they are reading this: thank you all. ↩︎
Technically a very small team, which does not include me. ↩︎
This is actually another old idea come around again, we did something similar in our pre-Gutenberg sites via ACF. ↩︎