Future of the MegaQC Website

[Zethson]

Dear everyone,

as discussed we could go for a somewhat nice simple website with a documentation button in the navigation bar, which links to the documentation. A nice website makes any project look serious and aids in motivating people to contribute.
Documentation related issue: MultiQC/MegaQC#117 (comment)

My suggestion would be the following:
Again - example mlf-core: https://mlf-core.com/index
I shamelessly copied the style of the nf-core website and adapted it slightly. Like discussed it links to the documentation.
We aka I could yet again copy the website and modify it for MegaQC.

Advantages:

• I am familiar with the code and could do that in a short amount of time
• Backend is Flask based, which is consistent with MegaQC and allows people who contribute to MegaQC to also contribute to the website
• Frontend was designed by @ewels which means that as a frontend wizard he can quickly modify it
• It looks good and would be a low hanging fruit to start out with

If you consider this a good plan I can write a slightly more detailed proposal and we can discuss that further.

Thoughts @TMiguelT @ewels @apeltzer @tsnowlan ?

Cheers

[ewels]

I'd prefer not to copy the nf-core website design. If we're going to copy a front end, I think https://multiqc.info would be more fitting. Code: https://github.com/ewels/MultiQC_website

[Zethson]

@ewels Perfectly understand.
The MultiQC website however is php based, right? Extracting the front end from that might be really annoying.

We could also go for a completely new front end from scratch with a Flask backend.

[multimeric]

I don't think we need a backend at all. I would stick with a static site. Either we abolish this repo entirely and do everything through Sphinx, or we keep this and use HTML as it is now, or perhaps move to Jekyll or some other static site generator.

[Zethson]

Don't think that we would need one right now either, but then you always have the option to just use it when needed. But with a static site you can also add the backend later when it's actually needed. Fine with a static site.

[ewels]

The nf-core site is PHP based as well..? Most of the MultiQC website is just static HTML anyway so shouldn't be particularly tough. It's only the docs that are doing anything fancy and we're using a different method there anyway.

[Zethson]

I rewrote the nf-core backend with flask for mlf-core. So: static website starting with the MultiQC design?

[ewels]

Sounds good to me 👍🏻 How we render the more custom static pages such as the homepage I don't mind - sphinx / Jekyll / Hugo / static HTML.

I have been wanting to play around with the Hugo + Sphinx combination for a while now but haven't had the time. When I was looking at it before I was thinking that Sphinx could generate markdown / rst and Hugo could then render that into the website alongside regular static content. That would be compatible with GitHub Actions / Pages etc.

But yeah - anything is better than nothing, so happy to go along with whatever static HTML approach 👍🏻

[ewels]

If it's only the homepage that will be proper "custom" HTML outside of the sphinx docs, it might be worth skipping the static site generator completely? Just have sphinx running into a subdirectory and a static index.html file in the root. Sphinx theme and static HTML using the same CSS assets etc.