For what it's worth, we recently converted the yt website into a generated
static site.  It was based on boostrap before, but we upgraded it.
Repository is here:


It's set up to auto-build and deploy.  The auto-generation is used to list
contributors, gallery, etc, and it uses JInja2 for templating.  Jinja2 is
required for Jupyter Notebooks, so we didn't see it as a problem to mandate
it for viewing locally.


On Tue, Sep 20, 2016 at 10:37 AM, Frank Loeffler <kn...@cct.lsu.edu> wrote:

> 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
> _______________________________________________
> Users mailing list
> Users@einsteintoolkit.org
> http://lists.einsteintoolkit.org/mailman/listinfo/users
Users mailing list

Reply via email to