[Users] web site development

[Frank Loeffler]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20160920/18ac01b0/attachment.bin