Hi, 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:
https://bitbucket.org/yt_analysis/website 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. -Matt 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 Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users