Update webpage

[cschwan]

We have a webpage at https://n3pdf.github.io/pineappl/ using gh-pages and we should update it!

[felixhekhorn]

We want to do something similar in EKO - and I believe the main purpose of that page should be 1) advertisement and 2) pointing the interested user to the details;

here are my suggestions:

• the page has to become hierarchical, I believe, since there is too much to show
• Installation:
  • you have to decide where to maintain Rust/C instructions:
  • on the website
  • in the repo
  • on crates.io
  • for Python we already pointing to rtd
• Interfaces:
  • list them together with the examples
  • e.g. for Fortran pointing to the repo should be enough
  • Python -> yadism, pineko
  • C -> madgraph
• CLI (I known, formally belongs to the former, but there are so many commands)
  • list all commands together with a brief example
  • e.g. comparing a grid with an FK table
  • don't show the --help since you don't want to maintain it in three places :upside_down_face:
• A physics section with maybe more relevant examples: "with this mg5 runcard from the runcards repo + this cli command you get this, and that is interesting because it shows that for this measurement you can neglect EW corrections" or similar ...

[alecandido]

A physics section with maybe more relevant examples: "with this mg5 runcard from the runcards repo + this cli command you get this, and that is interesting because it shows that for this measurement you can neglect EW corrections" or similar ...

I guess it should be "you can not neglect..."

[cschwan]

@felixhekhorn I agree with every point, that's a very good list. I wonder whether we shouldn't have a single homepage for each of our tools but instead one homepage for all of them; you already mentioned runcards, which uses also yadism and then we have of course also EKO and PinEKO.

This homepage would then mainly serve as an overview and explain what is what, where you can read details and showcase a few examples. Nevertheless we should have everything you mentioned, but maybe in different places.

[alecandido]

@cschwan I believe we can do both:

• individual home pages for the tools, that are more frequently updated (e.g.: at relevant releases) and contain tool-specific information
• a toolchain home page, with overall information and tools description (but without technical information, e.g. about CLI and installation), redirecting to the individual home pages

[felixhekhorn]

have a single homepage

Mmm, not so sure, because that one would be bloated - look at the list, this is already quite some stuff; and for eko I expect a similar order of magnitude, since we want to use that one e.g. to show more benchmark plots

we can do both

agreed

[cschwan]

I made a small change: when you go to our homepage https://n3pdf.github.io/pineappl/ it'll no longer show a markdown file from gh-pages, which was completely outdated, but rather the README.md from master. Alternatively we could show docs/README.md, which might be better. In any case the homepage should be automatically much better maintained now.

[felixhekhorn]

I like the change ;-) (this also resolves my doubts on where to maintain ...); if I may add some comments:

• 21

• maybe we should place the links to our competitors not as the first thing, but a bit below ...
• the installation section is quite long now, maybe we should split a bit? (á là "the short cut is cargo install otherwise look there")
• the link to CONTRIBUTING on the website is served as a file and not as a redirect to a page

[alecandido]

• the link to CONTRIBUTING on the website is served as a file and not as a redirect to a page

This I don't fully understand why, maybe try with [...](./CONTRIBUTING.md)? (there is a slight chance it is checking for slashes in the source)

• the installation section is quite long now, maybe we should split a bit? (á là "the short cut is cargo install otherwise look there")

I agree, we can put an extended installation section in the docs (just another markdown file), in order to have a cleaner home, serving more as an introduction and table of contents (rather than being itself a guide to something).

[cschwan]

I moved the installation section into a separate document in commit 53cef3eb1b25a73a78c12e03e56326c8beab7022.

[cschwan]

The problems with the website I collect here: https://github.com/N3PDF/pineappl/issues/146.

[cschwan]

@felixhekhorn I'm thinking of reworking the README a bit, as it's the first impression. I think the best would be show some nice plots and tables to show off what PineAPPL can do.

[felixhekhorn]

@felixhekhorn I'm thinking of reworking the README a bit, as it's the first impression. I think the best would be show some nice plots and tables to show off what PineAPPL can do.

that's a good idea - however, there is a trade off to be made: how much to show on the front-page without make it bloated? (on a separate page one can be as detailed as one likes)

[cschwan]

I believe most points have been addressed. Please open a new Issue if that's not the case.