Let’s start figuring out which content exactly is necessary to be presented on the website, and after everyone is happy with it - we’ll proceed with actual website design.
I’ve converted all content to markdown and did initial clean up, leaving only three pages: Home, Development and Download. Here is a website build by Jekyll: https://gcmd-website-dev-f1890d.gitlab.io/ . Source will be shared a bit later. Please don’t be alarmed by the lack of any styling - main focus is on content for now. Also apologies for repeating website title and page titles. Many headlines were left as is just to make communication easier.
And along with this preview I made a long list of tasks/questions to figure out about content on the website. Please take your time answering and bring your own ideas.
Initial content cleanup and structuring
Application name: “GnomeCommander”, “GCMD”, “GNOME Commander” (in application title), “Gnome-Commander” - select one and use only it on the website. Now it is a bit confusing having several names.
Do we need a section (block) to display latest release version number and release date? Link to dowload page?
Should some badges (version tag, license, translations, pipeline status) be kept on new website?
Consider reducing content on website by moving some more technical information to documents in repository, like README.md and CONTRIBUTING.md? Or linking to other websites, e.g. information regarding translations (those are standard processes for all GNOME progress, and might change in the future). gentoo build section sounds like it surely should end up in “BUILD.GENTOO” document. GitLab repository sections could be better utilized, like releases or wiki.
Do we want to display more application screenshots on homepage or other pages? I’m not a fan of carousels or thumbnail/lightbox solutions. Having one or two screenshots from application inline might be more than enough.
Coherent punctuation in lists: either we end all with dot or semicolon or nothing at all, but not a mix of various options.
When to use “code line” (backticks), and when to use “code block” (three backticks block) formatting? Long shell commands does not fit on mobile screens.
Should we add “copy to clipboard” button to code blocks, as some visitors might expect such feature?
Main page/Index/About
Rephrase “kill bugs” into something more neutral, like “fix issues”. Maybe “bugs” section should be renamed to “Issues” or “Reporting issues?” to match vocabulary used in GitLab.
Display organization names in donation links, not URLs? Add more? Remove something?
Download
Add more Linux distributions to pre-built packages: Ubuntu, Slackware? Maybe some more big names are missing?
Development
Rename “Development” page to “Contribute”, as there are more ways to contribute than only development. Check Welcome to GNOME – Files for inspiration on how to lay out all the information. Adding section about quality assurance and security testing would be useful.
Link current/future plans to appropriate milestones in GitLab?
“current stable” branch number in terminal command quickly gets old. Nobody is going to update this after each release. Some clever workaround is needed here. Or a command line to quickly find latest stable version number.
Building from source: it would be useful to list what dependencies are required to build project. No need to list every one for each distribution, but some general list. Probably should be moved to repository, along with all technical information.
Compendium/compendia? What is the difference? What is correct spelling?
Update application title and new URL of “Gtranslator”
Ask someone from translation team to review the “Contributing by Translating” section. Maybe link to official GNOME docs?
Design and layouts
Do we want to display slogan “A powerful file manager for the GNOME desktop environment” under application title in navigation bar (header)? Or move it to about section and keep header clean?
Is current layout “External packages” looking good? Should we simplify it by making icons larger, so tap targets would be bigger on mobile? Would be nice to keep this part simple and not to go building custom HTML layouts. We could use distribution logos with names inside them. There is always alt text available for accessibility.
Use 4:3 aspect ratio for screenshots to fit all screens better and showcase more content.
Dark mode and use application screenshot taken in dark mode in it.
Final cleanup
After website is complete, update “Updating the Homepage” section. New link to website repository, info how to report issues and create MRs with content changes.
Run a spellcheck and grammar check on all final text.
Check all external links, if any are broken or being redirected. Use direct links whenever possible.
Go through ALL software download websites and figure out how to update gnome-commander to latest version, as most have very old versions showcased.
Apologies in advance for large wall of text. We can work on one section at a time 
.
