Re: [Users] web site development
On Tue, Sep 20, 2016 at 1:58 PM, Frank Loeffler wrote: > On Tue, Sep 20, 2016 at 01:27:28PM -0500, Matthew Turk wrote: > >> 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. >> > > Thanks. I don't think requiring Jinja2 would be an option, but I would be > interested to know why you switched. Was is something it couldn't do or > couldn't do they way you wanted? If so, what was that? > > Oh, sorry, it is *still* based on bootstrap. We just now use Jinja2 to generate the site, instead of manual HTML editing, copying things around or server-side includes. > Frank > > ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Re: [Users] web site development
On Tue, Sep 20, 2016 at 01:27:28PM -0500, Matthew Turk wrote: 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. Thanks. I don't think requiring Jinja2 would be an option, but I would be interested to know why you switched. Was is something it couldn't do or couldn't do they way you wanted? If so, what was that? Frank signature.asc Description: Digital signature ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Re: [Users] web site development
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 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,
[Users] web site development
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 signature.asc Description: Digital signature ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Re: [Users] meeting minutes for 2016-09-19
On 19/09/16 17:21, rh...@illinois.edu wrote: > * (summer) student projects on > https://docs.einsteintoolkit.org/et-docs/Summer_student_projects > * ELoisa suggests to try and apply for a google summer of code project for > some of the projects Hi! It wasn't actually my suggestion, but I said I'd be happy to collaborate on an application. For the record, the deadline should be in mid February. Best, Eloisa ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
