New homepage design

[pieterdd]

This PR repurposes a draft for an opensuse.org redesign as the new homepage for get.opensuse.org. From what I understood in the Matrix chat, the marketing team would like to use opensuse.org to promote not just its operating system. get.opensuse.org can focus exclusively on the operating system.

Full i18n support is present, so I assume that the new translation keys will be available from Weblate after merge. I haven't gotten to the other pages yet, but this is a separately releasable increment.

Icons are sourced from uxwing.com under this free license Google's Material Design icons under an Apache license.

[pieterdd]

The sizes task hit the following error:

Faraday::ConnectionFailed: Failed to open TCP connection to mirror.rackspace.com:443 (getaddrinfo: Try again)

I don't think I have the access rights to restart the job.

[hellcp]

A lot of the contents of this PR should be moved to the theme repository! Thankfully updating the template doesn't automatically update all the sites, so we can take it slow page by page

[hellcp]

I think the frontpage should probably just use a default fallback for all the pages. That way you make sure to have the metadata of all pages make sense even if not explicitly set

[pieterdd]

If I understand correctly, you'd tweak the fallback to be suitable for the homepage, and then use the fallback on the homepage?

[hellcp]

Yes

[pieterdd]

Done!

[hellcp]

My general concern about using self rolled css is that it makes it harder to create new things with it, as you very often have to roll more of your own css overtime. Would it be possible to have a look into using a css framework of some kind? This far we have used bootstrap that was customised to out needs. That allowed us to get applications like https://calendar.opensuse.org and https://paste.opensuse.org rolled out quickly based on existing css components. I don't think customising an existing framework to make it close to this theme would be very difficult, but it would require a decision of what we may want to adopt, and how we want to share it between websites.

[pieterdd]

I understand the appeal of a CSS framework like Bootstrap or Tailwind, and I've used such frameworks before in past projects.

You don't want to spend time reinventing the wheel, so a reusable set of components sounds like music to your ears. You simply have to write some HTML tags, while letting designers take care of the cosmetics. That's an interesting proposition.

Throughout the homepage, I don't think I've reinvented any type of component that Bootstrap or Tailwind provide, so it would not have helped. There is however a reasonable chance that the download pages might need some components a CSS framework could provide. I'd probably want to modify the default styling so that it better fits the look I'm going for. Modifications to third-party styling might break in subsequent versions of the CSS framework, and you only have a limited amount of control over its styling. At this point I'd be spending more time tweaking the framework's styling than writing a few lines of CSS I have full control over.

Another reason I've used CSS frameworks in the past is for layouting purposes. In the case of Bootstrap, you've got a system of CSS classes to describe somewhat rigid grid-like layouts with. At that point, you're just doing layout in HTML instead of CSS. Problem is, HTML is worse at layouting than CSS. When making websites mobile-friendly, it helps to have full control over your layout. Shrinking font sizes on smaller screens? CSS has got your back. Completely rearranging three design blocks on mobile? Easy peasy with CSS Grid. Much like inline styling, Bootstrap uses HTML for both content and layout, while in reality HTML is better at content and CSS at layout.

By default, CSS frameworks also weigh down your page load with features you don't use. In Bootstrap's case, the framework also requires JavaScript. Some frameworks have a customization system allowing you to only add framework code to production builds that is actually needed, but this generally requires more complex development tooling where vanilla CSS doesn't.

The layouts at https://calendar.opensuse.org/ and https://paste.opensuse.org/ look like things I could build in the same time or less than it'd take me to do it in a CSS framework. So at that point I wonder, what do CSS frameworks still have to offer me? Reusable components at the cost of limited flexibility. Less control over my responsive layout. Slower page loads and a corresponding SEO penalty. In some cases a more complex development pipeline. A worse separation of concerns between content and presentation.

Granted, a lot of people use such CSS frameworks, and their websites turn out okay. So surely frameworks must be doing something right. But personally, I would not add the friction of a CSS framework to this project at this point.

[hellcp]

I'm mostly asking because of code reuse, but if you are willing to spend the time on building common components yourself and then specific components for specific sites, I'm not going to stop you

[pieterdd]

We can defer the choice until I need a component that Bootstrap (or another CSS framework) already provides. So far I haven't needed one yet.

I do want to note that when it comes to building reusable design components, Jekyll is not our best option. We can write {% include %} tags with parameters, but my main concern is that relevant CSS cannot be encapsulated. Frontend frameworks like Vue and Svelte have the concept of a single-file component, where the HTML and CSS of a design block can be encapsulated within one file. CSS in a single-file component can never cause CSS bugs outside of the component because it's scoped to just the HTML in the component, and the CSS is only loaded once if you use the same component multiple times in one page.

Speaking of Jekyll - having given it a fair chance now, I also want to note these drawbacks I noticed:

• A simple code change takes about 9 seconds to regenerate the page, despite get-o-o being a relatively simple codebase
• Jekyll's ecosystem doesn't seem that vibrant. I went looking for a Jekyll plugin to minify HTML/CSS for performance reasons, but only found plugins that hadn't seen any development activity in the last few years and didn't work properly.
• Ruby is not as well-known as something as omnipresent as JavaScript, which may cause friction for potential contributors who aren't already Ruby devs.
• My IDE's code formatters for HTML and SCSS don't recognize Jekyll's front matter and Liquid syntax, so I had to disable them. This makes it a bit harder to keep the code clean.

I realize that venturing outside of Jekyll requires doing a few things a bit differently, but we're still at a point where changing to something like SvelteKit (which can produce static websites you can deploy on any Apache) or Vite + Vue is feasible. We can also still go for React, which is less pleasant to write CSS for than Vue/Svelte, but is an industry standard that contributors are most likely to already have experience with.

[hellcp]

get-o-o is rather unique in terms of how long it takes to load because of the plugins that are slow to apply, for most other websites it would usually be less than a second.

[pieterdd]

I think this would be a lot faster in most JavaScript-powered frameworks.

Are you open to a Jekyll alternative that renders faster with plugins, is more suitable to create reusable components with encapsulated CSS, plays nice with IDE formatters, has a sufficiently active third-party plugin ecosystem and can be extended in a popular language most developers have experience in?

[cboltz]

The main reason why generating get.o.o needs some seconds is because it includes the file size of all downloads in the page - and to be able to do that, it requests each file from download.o.o (and possibly gets redirected to a mirror) to get the file size (see Rakefile).

I slightly doubt that another framework will be faster in doing these requests ;-)

[pieterdd]

Fair point regarding performance. Are you otherwise fine buying into Jekyll again for a redesign? I have the impression that the development community around Jekyll has been decaying for a while, with the unmaintained plugins for HTML minification malfunctioning and whatnot.

It doesn't seem that hard to change to a different stack at this stage, as static site generators don't require any server-side infrastructure. But I understand that migrating to something you might not be familiar may come with some reservations.

[hellcp]

Most of the functionality we add is custom enough and it's easy enough to write a jekyll plugin or a simple rake script that I don't really see much need in making use of what the community around jekyll makes.

[pieterdd]

Could you resolve the review threads that are no longer actionable so I can see what's still relevant?

[hellcp]

I will want to do a more thorough review of the design, I only did a short review of the immediately visible issues this far, sorry that this is taking this long, it's a rather big PR

[pieterdd]

Alright, no worries. In the meantime, since I noticed the existing site has both a light and dark variant, I started implementing a light variant as well. Sneak peek:

[hellcp]

I think we should do a cobranding of openSUSE and Get, to make sure that people understand that this link leads to this website and not to openSUSE.org. You should also not use . as the url, since that doesn't make much sense

[pieterdd]

I agree that the site can do a better job of clarifying the hierarchy between opensuse.org and get.opensuse.org. However, the "Get" title on get.opensuse.org confused me the first time I saw it, so perhaps I could find another way of clarifying the difference.

Could we change the "Get" to something that better clarifies the purpose of the site? We could write something like "openSUSE OS" or "openSUSE distro" to clarify that get.opensuse.org is about the Linux product (as opposed to the build service for example). Perhaps I could add some kind of "up one directory"-style arrow to the left of the logo to clarify that this is how you return to opensuse.org?

[pieterdd]

I played with the branding some more more. Replacing 'Get' with 'Linux' feels like a clear way to communicate the purpose of get.opensuse.org. It's the website with all openSUSE Linux flavors.

[pieterdd]

One issue I noticed with universe.rb (the script that fetches https://universe.opensuse.org/api/v0/en/sites.json) is that it sometimes produces HTTP 429 exceptions:

10:42:46 PM:   Liquid Exception: 429 Too Many Requests in /opt/build/repo/_layouts/default2025.html
10:42:46 PM:                     ------------------------------------------------
10:42:46 PM:       Jekyll 4.4.1   Please append `--trace` to the `build` command 
10:42:46 PM:                      for any additional information or backtrace. 
10:42:46 PM:                     ------------------------------------------------
10:42:46 PM: /opt/buildhome/.local/share/mise/installs/ruby/3.4.3/lib/ruby/3.4.0/open-uri.rb:393:in 'OpenURI.open_http': 429 Too Many Requests (OpenURI::HTTPError)
10:42:46 PM: 	from /opt/buildhome/.local/share/mise/installs/ruby/3.4.3/lib/ruby/3.4.0/open-uri.rb:825:in 'URI::HTTP#buffer_open'
10:42:46 PM: 	from /opt/buildhome/.local/share/mise/installs/ruby/3.4.3/lib/ruby/3.4.0/open-uri.rb:233:in 'block in OpenURI.open_loop'
10:42:46 PM: 	from /opt/buildhome/.local/share/mise/installs/ruby/3.4.3/lib/ruby/3.4.0/open-uri.rb:231:in 'Kernel#catch'
10:42:46 PM: 	from /opt/buildhome/.local/share/mise/installs/ruby/3.4.3/lib/ruby/3.4.0/open-uri.rb:231:in 'OpenURI.open_loop'
10:42:46 PM: 	from /opt/buildhome/.local/share/mise/installs/ruby/3.4.3/lib/ruby/3.4.0/open-uri.rb:163:in 'OpenURI.open_uri'
10:42:46 PM: 	from /opt/buildhome/.local/share/mise/installs/ruby/3.4.3/lib/ruby/3.4.0/open-uri.rb:805:in 'OpenURI::OpenRead#open'
10:42:46 PM: 	from /opt/buildhome/.local/share/mise/installs/ruby/3.4.3/lib/ruby/3.4.0/open-uri.rb:29:in 'URI.open'
10:42:46 PM: 	from /opt/build/repo/_plugins/universe.rb:15:in 'Jekyll::UniverseData.setup'

I'm assuming that https://universe.opensuse.org/api/v0/en/sites.json is throttling the Jekyll requests because they're being repeated several times. Would it be possible to cache this resource during the rest of the Jekyll build? I don't have much experience with Ruby and Jekyll plugin development so I'm not yet sure how to proceed.

[hellcp]

I'm thinking it might be better to do the same thing we do for fetching Tumbleweed versions and fetch the universe into _data. I will investigate it whenever I have the time

[pieterdd]

I think I've now more or less done all changes I still intended to make to the homepage, and there's also a bugfix at openSUSE/universe-o-o#7.

Once we have multiple pages within get-o-o running on the new design, that might be a good time to move the templates into the openSUSE Jekyll theme. Keeping the layout and any reusable includes in this repo for now makes it easy to iterate and polish while they're still changing a lot.

[pieterdd]

Could you close solved threads so I can see what's still actionable?

[TobiPeterG]

Is there any progress on this? :)

[pieterdd]

I'm waiting for further instructions from @hellcp. As far as I'm aware, I've addressed all open threads.

[hellcp]

Apologies, I've been rather busy and things aren't getting any lighter before oSC

[lkocman]

A little update from oSC. We could perhaps merge this into a separate development branch. And productize this as we progress on updated branding etc. Would that be fine with you @pieterdd ?

[lkocman]

Let's have this done by end of the next week.

[lkocman]

@pieterdd please submit it to https://github.com/openSUSE/get-o-o/tree/devel

[pieterdd]

Personally I'd take a different approach. My goal with this pull request was to make the first of a series of separately releasable increments. Pages that haven't been converted to the new design yet can co-exist without causing layout issues.

This increment has been in the works since half of April, and I finished implementing the last batch of review remarks so far around half of May. I have the impression that available review bandwidth is quite limited, that the existing build pipeline is somewhat fragile and that the release process is somewhat tedious compared to GitHub Pages or Netlify. These factors may affect our chances of achieving the 100% finished point before burnout.

The question then is: if we never reach 100%, which is worse? If we don't release incrementally, all work risks ending up in a GitHub graveyard like the previous website redesign attempt and no one will ever benefit from it. That would be a very undesirable outcome for me, because then I'd have preferred to donate that time to other projects where I could have had impact. I'm sure my reviewers also prefer doing things that have real-world impact.

If we work in separately releasable increments - which agile practice recommends over big-bang releases - users might see some aesthetic inconsistencies, but the fruits of our labor will at least reach users no matter what happens down the road.