godotengine
Requirements for redesigned website
Compiling a list of requirements and desired capabilities for a future state of http://godotengine.org. This discussion is intended be focused on capabilities of the website, and not on specific technologies to achieve them. Please leave suggestions and I will compile them into this list!
Note: This initial list is just my recommendation and starting point. Please feel free to comment with anything we should add / remove / modify
Top website values
These values will help drive trade-offs on what kinds of technologies and processes to be selected. Each decision should relate to one of these values.
Translation / Localization capable
The website today only is only available in English. Allowing non-english content is a big no-brainer to expanding Godot's reach. The site should be able to accept translations from the community easily to continue to grow translations easily.
Private environment for creating / publishing blog posts
The blog is one of the largest official channels for Godot. Many blog posts are time gated by nature and need to be created and published in a non open channel to ensure announcements are available only when the time is right.
Self hosted
As an open-source project, the website needs to be able to keep itself running even as contributors shift and change over time. Being self hosted decreases reliance on any particular vendor and de-risks the site failing due to neglect.
Simple to contribute non-blog content
It should be easy for anyone to contribute typos, bug fixes, and other contributions without having to understand an overly complex system. The site should bias towards a simple design that makes contributing changes as obvious as error-resistant as possible.
Accessible
Developing games should be for everyone. The site should aim for as high a bar as possible for accessibility to allow as wide and as inclusive of an audience as possible.
This includes (but is not limited to):
- High contrast text
- Semantic html
- Native input controls
- Dark / Light themes
- Adjustable text size
High performance
Developers can be highly sensitive and critical of performance. The site should aim to create a site that loads quickly and takes up few resources to not only appeal to performance critical users, but also to reflect the lightweight nature of the Godot engine and development environment itself.
SEO friendly
Organic growth is driven by search engine results. The site should promote discovery and growth by allowing crawlers to easily find and scrape information from the site.
High priority features
Specific features that should be available with a redesign. Most of these should be accomplished within reason.
- Auto generated sitemap
- Light/ Dark mode
- Offer multiple download links for significant versions of Godot (4.0, 3.x)
Features to consider
- Host developer surveys on the site
- Easy to create keyword optimized landing pages
- Request intake forms
- RSS Feed for blog
Note that the current website supports automatic dark theme based on browser/OS preference (with light theme being the default if there's no preference). This should ideally remain in the new design for accessibility reasons.
As for performance, I recommend not relying on full-fat JavaScript frameworks at all if possible (small libraries are OK). For faster navigation between pages, integrate Barba.js as it's done on the current website.
As for performance, I recommend not relying on full-fat JavaScript frameworks at all if possible (small libraries are OK). For faster navigation between pages, https://github.com/godotengine/godot-website/pull/222 Barba.js as it's done on the current website.
Yeah agreed. I've worked on full client side websites and while it can be made to feel fast, there's a ton of JS that's pulled down into client for sometimes very little interactivity. Some newer frameworks do a much better job at shipping minimal JS. Some Server side rendered, static rendered pipelines let you get the nice DX of web frameworks without actually shipping a heavy framework down to the client.
Another thing I was thinking about is that the Download page should offer downloads for 4.0, but also for the latest 3.x release. It should also briefly explain why you may want to stick to 3.x for some use cases (mobile, HTML5, and targeting very old/low-spec desktop machines). I expect this will be needed at least until 4.1's release, which will have a production-ready OpenGL ES 3.0 renderer (targeted for low-end GPUs).
The 4.0 downloads should be made more prominent, but it's important that the 3.x downloads aren't too hidden.
Added a requirement to show multiple downloads of Godot. I kind of like the way Node does it by giving you all the versions but include the support timelines and make sure you're informed on why you would want to download one over the other. https://nodejs.org/en/about/releases/
What do you think of Nextjs. It meets all expectations.
If we choose nextjs I want to do the infra. And I thinks create an repo like
beta-websiteorwebsite redesigncan be a good starting point.
We have transitioned to a different stack since this issue was created. While it still highlights some of the key points we need to address (i18n, accessibility), by and large this is already solved with the move to Jekyll. We are definitely not looking for another change in the stack soon, unless it provides some huge benefits to the maintenance and usability.
