Hi,
Our website needs an update. This can usually mean two things, and in our case it means both: content update/refresh and/or web technology update.
This email and discussion should only be about the latter: which web technology to use. This email also got quite long. If you don't feel like reading through all this, please at least skip to the last paragraph and read that.
What do we have now?
Status quo is hand-written html with usage of php on every site, but mostly only for includes. There are exceptions, but there are only a few, and they can always be treated special.
Why should we change the current setup?
1) The usage of php makes it necessary to use a local web server to view the pages before committing. While this isn't usually a big problem, because installing a small php-capable webserver is easy, it is a hurdle we rather shouldn't have when we want people to contribute to the pages.
2) The web layout doesn't look particularly nice on tablets, or even phones. While that was fine when the site was created, this should be addressed nowadays.
What could we do instead?
There might be more than these two issues (please speak up if you have more), but in the following, I will go only go into these two; separately because they don't really depend on each other in any way.
1) php We use php mainly to include common snippets, like headers and/or footers. php does this server-side, but because this requires a server to view the pages, we would have to use something else. There are only two possibilities. Either we do includes client-side, or we do them before the server sends out the pages: developer-side.
Client-side the only available option is java-script, as that is the only 'active' component that is widely available client-side.
Developer-side would mean that every web-developer would need to process includes after each change to the web pages, and would hand the result over to the web server. This can be automated, such that after each change to the repository a script (on the webserver) runs this step and creates the then static web pages. Requiring compilation on the developer-side would mean to require that every developer would need to install the tools needed for this, a situation we tried to avoid in the first place (local webserver). It would also mean to commit generated files into the web-repository, which in general is a bad idea. On the other hand, automating this step on the server would mean that the web sites couldn't be viewed locally again without installing the necessary tools.
I would welcome something else than javascript that would work client-side, so we wouldn't depend on it being enabled. However, I am not aware of anything in that direction, so I see it as the best of the alternatives that we have.
2) layout The problem here is that it is difficult to create pages that look good both on large (desktop) and small screens (phones), especially if you think about plain html pages. The "usual" (as in often-used) solution is to change the layout of the page slightly depending on the size of the screen. Html doesn't allow for this, so again we arrive at javascript. There are probably tons of frameworks that implement common elements for so-called "responsive" web pages. Don't hesitate to throw in others, but I'll go on show-casing one I did play with.
That one is called "Bootstrap". I am not saying it is the best, but it is one that seems to be widely used, open source, actively developed, and has tons of documentation. So I went ahead and used it to create a (not quite mock-up anymore) page for Chemora: https://chemoracode.cct.lsu.edu/ Note that this isn't mean to be a final "product", but it shows the basic feature of a menu. That menu is a simple top-navigation bar if inside a window that is wide enough to show it. If the windows size gets too small (you can try that yourself by just resizing your desktop window), this bar gets replaced by a pop-up menu. Feel free to look at the source code. You won't find a lot of scripting inside the actual pages. Most of that is hidden in files that are included, and most of that is inside the bootstrap library itself (that you don't really need to look at at all).
How to get involved?
I will have a student at LSU go through the pages and "improve" them, creating a "preview" first for everyone to look at. However, apart from a more "modern" page, one prime objective is to make it really, really easy to edit those pages, for every developer. Please share your opinion about how to edit/compose our web pages. How would *you* like to edit and view them?
Frank