Semi-fixed bottom navigation

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.

So now, this solution looks at the footer. It figures out how tall it is. Then it looks at where you’ve scrolled to. When you get to a certain spot, it’ll move the fixed navigation upward to keep the footer at the very bottom. When you scroll back up, it’ll put it back at the very bottom. It’s javascript with a bit of css transition to make it smoother.

See the Pen
footer spy fixed by Tom (@twwoodward)
on CodePen.

Aside

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 purchases¹ 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.