The author uses the example of a calendar buried on an institution's website and asks some questions about why the master calendar isn't published directly. Th

The author uses the example of a calendar buried on an institution's website and asks some questions about why the master calendar isn't published directly. This collides with an unfortunate reality about the milieu that most Web-related work happens in: the Web is largely regarded as a sui generis medium that isn't actually supposed to be useful to anyone—at least not for its original intended purpose. Its usefulness is incidental to the imperative to produce something—anything—and the foremost concern is that that thing merely exists. The prevailing view, even ("especially"?) among people who make their living doing Web work, is that a website is not actually supposed[1] to serve as a document store for the organization it ostensibly is set up to serve. Instead, it's boondoggle; the primary purpose is to signal maturity. "Do we have an app?" "Yes, we have an app." "Do we have a website?" "Yes, we have a website." These are the questions that people are interested in, like checkmarks on a line item list. The utility of these things is not a concern. It doesn't actually matter that there's a calendar or whether anyone ever looks at it, or whether that SMB's listed opening hours are accurate and stay up-to-date over time, or whether the lunch menu is available, let alone at a stable URL. Because where is the heavy lifting really supposed[1] to happen? Answer: somewhere else. On the Facebook page, or via Twitter, or through Substack, or in Office 365 or Google Workspace[2]. Sure, you hire someone to make a website, maybe you have an IT department that can "maintain" it so you can periodically file tickets to get something changed when you want to feel like you put in some work today. Of course. Of course! That's what you do. But to expect it to actually be useful? What are you, nuts? 1. Related reading: Ra <https://srconstantin.wordpress.com/2016/10/20/ra/ https://srconstantin.wordpress.com/2016/10/20/ra/> 2. Or, as in the case with many of the people who are in the industry: on GitHub. ("Why would we document the processes related to foo.example.com in the document depository we have running on foo.example.com? That's what the README in the associated ghost repo on GitHub is for.")