This is another solution for the social science research site. Each fix seems to spawn a new minor, yet complex, problem. It’s easy to see how some web site costs get out of control. Hopefully this one will be the end of things.
In our previous episode, we made a fixed bottom navigation to standardize things and to avoid some other problems detailed in the previous post. I’d dealt with the footer overlap just by adding some padding so it’d end up above the navigation. Admittedly, that was kind of a sloppy solution.
There is a larger consideration I need to figure out for Middlebury projects. In the pay-by-the-hour world, it’s much easier to paint cost/benefit options for additional features or changes of various kinds. It’s easy to say. Sure. We can do that. It’ll cost this much. Worth it?
That economic model isn’t really present here so there’s nothing particularly solid to constrain choice. It’s a problem that happens in a variety of areas. Our academic software purchases1 don’t end up billed to the department but rather end up paid by our IT group. I believe that leads to some very different purchasing patterns. This is all fine in a world of plenty but it starts to have real problems once resources are limited at the upper level. That can be less people to do web development. That can be more projects with the same people. It can also be a more limited budget for software purchases. Changing from a culture of plenty to one of limited resources is a hard thing to navigate while keeping partners happy.
1 Some of them anyway. That’s another post. Likely a book of some sort.