When we launch the “live” web site we will definitely have a page(s) for each sub-project, and will probably follow the URL syntax you mention. Some other folks are working to set up those GitLab pages for the new web site so I’ll defer to the ones already thinking about that.
should that repository then contain the source code for the website and the actual modules code? so after each commit static site is generated and pushed to a separate branch.
We should be able to get this created through gitlab pages. It support multiple static page generators and I like that the runners are pretty fast. Jekyll is great, but we could do more with Hexo which has a powerful set of plugins.
Using gitlab pages for documentation also works nicely. A few hrs back I was telling @phoenigmatic bout using gitbook to write radiology user stories. @rallam92 has also migrated most issues from JIRA into her repo, that we can move to the librehealth-radiology project. @jayanthkumar17 also said he wants to help, but needs some guidance of where he can contribute to librehealth.
I think that would be enough content for now. After the initial setup we will of course evolve its content.
For the looks of the page:
I would love to see a nice radiology logo and a nicely looking page, but Im no designer so the only thing I can help you with here is say I like it or I dont like it
Also I wouldnt think to much about this now.
For the logistics/technology:
I like having docs (by docs here I mean the website) and code in one repo. If they are separate it will most likely not be maintained as well.
For static site builders: there are a lot. Can be overwhelming. Ive seen a talk about https://github.com/gatsbyjs/gatsby which is a static site builder for reactjs (built on reactjs). You can see a list of example pages there. But to get started we are probably ok with mostly markdown.
Whatever you choose it will be good enough for our purposes so dont worry
Other than that take initiative, feel free to try out different things and have fun!
Hi @rallam92, I know you’ve chosen zim, but then it means that you have to write HTML code or use the zim desktop client to write content… Zim is a nice desktop wiki, but with a host of very nice static site generators out today, it is a little old and takes you away from content and haggle with markup. I suggest that you use Jekyll or gatsby (like @teleivo suggest) because these can take Markdown or simple text and transform them into nice looking htmls. Jekyll has a nice community and a large number of new themes are created everyday - http://jekyllthemes.org/.
Ruby might be a turn-off with jekyll, so if not zim, why not gitbook? If you are going with gitbook for documentation, it seems a little silly not to use that across the board since it is perfectly capable of generating stylish html.
Personally, I find that the new templatee-page generating modern stuff tends to format a tiny bit of information around a ton of eye-candy.
I dont expect anyone to be building the site locally, so I dont think ruby or any else would be a problem. The GitLab shared runners will do all the heavy lifting and site generating. We just need an AsciiDoc/Markdown editor, which GitLab does pretty well at the moment. So edits can be done using the gitlab interface. So all in the browser, nothing locally.
I haven’t seen a lot of good stylesheets for gitbook… and its ToC structure doesn’t lend to the menu system that people are used to when browsing websites
After @teleivo’s recommendation, I did try gatsby… but the local tooling for it and unstable documentation was a lot to dig through. Might be frustrating to deal with since its not stable yet.
That link you posted is hilarious, but I think @rallam92 is more innovative. The top 4 links open new pages. there is multiple page layouts, if you look on the other parts. It also has a code sharing section that is different from that. It has more than 4 icons too
