Where Some Ideas Are Stranger Than Others...
Technical Longevity Versus Shininess (2020-11-02)
As often happens in medium to large organizations, one that I have done some website related work for has been going through a new cycle of major software purchases and customizations. These serve many useful purposes of course, in that this is a major means to apply important security updates and introduce new tools to manage changing aspects of data management in different areas of the work an organization does. Sometimes less useful but gratifying purposes like getting a fresher looking user interface or a few more helpful but not absolutely necessary features are met too. For the latter purpose, examples I can think of are things like multiple clipboards or an ability to run side queries in an extra window. Unfortunately, it is these happy and often useful extras that can decoy us into pursuing bling over keeping our eye on the real ball, which by rights is not shininess but maintaining the systems we need in a stable fashion to get our work done. I learnt the costs of losing track of the ball on this the hard way, and sympathize with anybody who gets caught by the decoy. It doesn't help that extra bling tends to cover over problems that we are also encouraged to expect the customization elements of the support contract will take care of. Would that we could depend on that!
One of the projects I have had to work on came down to a request to pull together and serve a diverse dataset for a large work group, while also ensuring that an even more diverse selection of ancillary files could be attached to that dataset. For ancillary files, read any major file format used for day to day work in an office environment, so definitely pdfs and the usual rogues' gallery of microsoft products. The dataset was so diverse that it actually didn't lend itself into being kept in the database software available at the time, and that software couldn't handle links to external files or otherwise perform a content management role. In the end what I did to build the project was create a website, with the dataset built up out of templated items that consistently labelled and structured the data. That way in due time when and if some other database-like approach turned out to be feasible, with some judicious scripting the data could be moved over. However, I also had to take into account some other details when putting together and implementing the site design that may or may not be common to such projects.
On the support side, there was no permanent maintenance team assigned to this project, nor any plans for one. That suggested that this project was supposed to be an interim solution, which made structuring the dataset all the more important. On the other hand, interim solutions in the real world often have to spend far longer in service than anybody ever dreamed, and all the indicators were that it would be a challenge to keep it resourced in terms of server space and editing software if it had to stay on a long time. That led me to do a couple of other things. First, I redesigned the site architecture twice to get that as solid as possible for the longer haul, including banishing the "Miscellaneous" folder. Second, after long and unhappy deliberation and testing, I settled on sticking with a website using structured templates that could be edited using a tool as simple as a text editor. No matter what myself and my colleagues tried, we couldn't persuade the standard database software available to us to work stably, and worse yet that software is terrible to figure out how to use. We also found out that licensing could be a real problem. If we built in a dependency on software that the organization no longer wanted to license, or that couldn't be licensed anymore because the software was no longer available or maintained, that would be a critical issue. So that meant rolling back to what could be managed with a text editor, a web browser for previewing, and nowadays, a version management system like git.
Practically speaking, this has proved to be a seriously robust approach. The website has now been chugging along for nearly twenty years. Because it is fundamentally a website, it can always be connected to other relevant systems, including setting up auto-queries and the like. Of course, if that step is taken then the challenge is to manage to keep up with those systems when they change their servers or their query forms, or have the plug pulled on them without a clear successor. But, even if that bit of flexibility goes a bit sideways because other relevant systems have their own problems, this project's core tasks are carried out independent of them, so it can stand on its own feet. While by no means perfect, the site is still doggedly doing its job and it is still being kept up to date on a rolling basis using basic tools. Alas, no git yet, which would be a truly marvellous thing to have, because then the number of editors could be easily increased. Still, that's a separate story and not a crucial one here. Of course, as you have no doubt already surmised, this old but working and stable website has a bling problem.
It hasn't got any.
It's not flashy or pretty. People complain it doesn't look like the wordpress layouts they are used to, that it doesn't have a thousand and one other bells and whistles uncontemplated in the original work order. They are frustrated that this to their eyes old-fashioned looking site has not been replaced by something glitzier that can do more things that would be of genuine use. It's just that those other things don't actually fall within the core functions of the website, and those are what have to keep working. On top of that, there is neither budget nor persons available to finally replace it, so the conservative approach to software used to build and maintain it is still necessary.
One of the fascinating things I have been learning from people responding to it who are not the primary users of the website is how for them its grittier appearance is conflated with it not being "user friendly" to them. The cause of the lack of friendliness is not its appearance but its underlying design and core functions, which were never designed to meet their needs. It makes sense that a person generally would conflate appearance with what is actually design and purpose mismatches, because people generally aren't designers and builders of websites whether large or small. Yet it also shows how we can all be so vulnerable to the shininess of bling, it is often what we fall back on when more crucial details are outside of our awareness.