Developing KeePassX Reboot website

[TheZero]

Hello Rebooter,

Now that we are taking the fork very seriously we should plan how to develop the official website.

I think it will be better as a plain static website, no blog no PHP. (maybe made with Jekyll)
Afterall we have Github Issue/PR and the Github Wiki, we just need a website that says "Download KeePassX Reboot or visit Github"
(website source can be uploaded on another Github repo in the organization)

What do you guys think?

TheZero.

[Janek Bevendorff]

I agree, but we should wait with that until we have a new icon to match the branding.

A static website is fine with me, it should be made mobile friendly though.

[droidmonkey]

Agree with simple website, I have no experience with Jekyll, can you explain?

Github has a new feature called "pages" that can translate Jekyll hosted in the repository into a webpage. That might be a decent avenue with just purchasing a domain name.

We also need to settle in on the official name of the project (KeePassXR?)

[TheZero]

Yes I agree that we need the name, the domain and the icon/color scheme, but if we have an idea of the website it will take less time when we are ready.

Jekyll is a system that use Liquid Template to generate static website.
It let you write post or pages and automatically apply the template so every post/page have the same theme (loaded from the same file)
A demo here: https://github.com/vuln-name/vuln-name.github.io

This is nice because Github Pages already use it and you don't need to buy a server or hosting space

[droidmonkey]

Cool, it might be best to make a new repository just for the website hosting under the keepassxreboot org name.

[TheZero]

Ok, so If we all agree on GithubPages and Jekyll, once we decide the fork name, I will start the new repo for the website!

[Manolis Agkopian]

I too agree with the static website approach, as I also see no need for an actual back-end or a database.

I think Jekyll is probably the best way to go for now. Additionally, I think we should also use a CSS framework, like Bootstrap for example, so we won't have to worry about things like cross browser compatibility and also that way get responsiveness out of the box and don't have to worry about the mobile devices either.

[TheZero]

Yep, fine for me.

I think no JS is needed.

A "beta" sitemap should be the following:
- Homepage --> with download button for the last version of mayor platform, a description of the project and the main feature)
- Download page --> with download for the last version of any platform, AppImage, Source Code, Nightly version maybe)
- Chanelog page --> with chanelog for each version
...

What do you think? Other Ideas?

[magkopian]

I think a bit of JavaScript is useful to help determine the user's platform so we can automatically use the right URL on the download button. There also should be an "Install" page describing the installation process using a package manager for all the major distributions, as soon as we manage to get a package included to them.

[TheZero]

Yes but for additional tutorial on the Installation and Usage we can use the GitHub Wiki (less pain I think)

[magkopian]

I'm not so sure about that, I think keeping everything on the same place would be a much better user experience rather than just putting a link to a Github Wiki. Also, that way we encourage people to fork the repository of the website, extend it and submit a PR.

Also, a lot of people tend to search for this kind of stuff directly on Google and Github Wikis from my experience tend to appear lower on the search results compared to the results of an official website. So, I believe that keeping this kind of information on the website would help people find easier what they are looking for.

[Janek Bevendorff]

GitHub pages sounds fine. If at any point we need more, I can easily host and manage a more complex website.

[TheZero]

But making a Wiki with Jekyll is pretty "hard", the Github Wiki instead is already done, it's easy to use, and it's git-centric.

We can write some basic tutorial on the website, but I believe that all the info must stay on the wiki

[magkopian]

What I was talking about is a page with some basic installation instructions for all the major distros, not a complete Wiki, please allow me to explain my thinking.

Linux users typically the first thing they will look for when they want to install a new piece of software, is how they can install it with their package manager rather than from where they can download a binary. So, if the JavaScript detects that the user is running Linux,
it could simply replace the "Download" with an "Install" button which will link to the "Install" page. The "Install" page doesn't need to have detailed instructions on how to setup and configure everything, just a couple of commands for each distro that can easily being copied and pasted in order to install the software.

Windows users look for a link to download the binary, Linux users users usually look for the command that they can use to install it. Personally, as a Linux user I love when websites implement this kind of functionality instead of simply putting a "Download" button to a deb file, and I'm pretty sure I'm not the only one.

[TheZero]

As a Linux user, I completely agree with your comment. +1

We must remember also that we have the launchpad PPA for Ubuntu, the AppImage (https://github.com/keepassxreboot/keepassx/issues/39) and generally this: https://github.com/keepassxreboot/keepassx/issues/5

[droidmonkey]

I love the Github Wiki, but a wiki has a purpose that is distinct from documentation. I think people miss that sometimes. Wiki's are designed for community based editing, and all the fluff that comes with that. Documentation should be aligned with the software, and as such, should be in lock-step with the software that is released. I see the GitHub Wiki as a great way to deliver rapidly relevant information, but not as the "official" documentation source.

[TheZero]

We already have part of the documentation shipped with the source code (see the README.md and https://github.com/keepassxreboot/keepassx/blob/develop/INSTALL), what do you think will fit as "official" documentation?

[droidmonkey]

I am talking about documenting the use of the application itself. Documenting source code is great and all, but not very useful for 98% of our audience.

https://github.com/PharkMillups/beautiful-docs

Some samples of great documentation.

I do think the source code could use a little documentation, but that might be better served as UML diagrams or System Diagrams.

[TheZero]

In my opition doesn't matter the way you deliver documentation (Github Wiki that is already done, a web site that you must develop, a file in the project source) but the important thing is what you write in the doc. For me using a tool or another is fine.

Github Wiki is less pain because is already done and works fine (it's not properly a Wiki, a demo here: https://github.com/TheZ3ro/penmode3/wiki), instead using post in Jekyll for achieve the same result will take some time.

[droidmonkey]

I prefer whatever is easiest to delivering the information we want to deliver.

[TheZero]

I'm starting to write the Installation guide for all the platform on the Github Wiki.

The nice thing is that the Wiki will be downloadable as a git repository where all the articles will be Markdown file.
If in the future we want to transfer the documentation on the Jekyll website (with a certain template) we only need to add the header part to each Markdown file