Updated CSS now that I've had more than a few seconds to look at it:

.container-xl {
  max-width: 100vw !important;
}
.col-12.col-md-9 {
	width: 85% !important;
}
.col-12.col-md-3 {
	width: 15% !important;
}
.react-repos-overview-margin {
	margin: 0px !important;
}
div[class*="Box-sc-"]:not(:has(img[src*="/images/modules/search/"])) {
	max-width: 100% !important;
}

These breakpoints (Thanks, Google, for making everything look like a phone, and marketing it so well that web devs - including your competitors - would follow your lead anyway) are insane. The xl sized container - that's the one meant for >1080p - that's 1920px wide, at least, and if you're on 4K that's 3840 ....max out at 1200px. That's the MAX. They just get skinnier and more margins for whitespace after that. Literally wasting AT LEAST 1/3 of your screen, if you're on 4K it's wasting AT LEAST 2/3 of your screen. What is this, GitHub? Did you even try it before you shipped it?

Here it is at 1440p:

Before:

After:

I'll keep updating as I get time to fine-tune this trainwreck, if github don't fix it themselves.

Edit: I just realised that one of my old CSS rules for fixing github's mobile phone UI on desktops, was playing into this, so I added it. Given that rule's been needed for the past couple of years, and they've just made it even worse, I don't see github ever fixing this themselves.

Edit: Added an exception to the width rules since the sponsorship box was killing search results 🤦 Fixed.

The only thing you gained IMO in your before/after Screenshots is harder to read text. There's a reason text is wrapped at certain character counts, to stay legible and let the eye easily find the next line.

I don't find it harder to read and I don't have problems with finding the next line. On the contrary, I have fewer new lines to deal with because it's not wrapped excessively tightly. (Now that I look at it, I have NO new lines to find, because it's not wrapped excessively tightly. You have to find 3, I don't have to find any. Doing nothing is easy!)

Perhaps it's because I'm old and grew up reading print on paper a lot, perhaps it's because I don't use a mobile phone which this UI is designed for, I don't know, but I don't need to waste large amounts of screen real estate to be able to read comfortably. I'd just get a smaller screen if that were the case, and then I'd still not want to waste space, I'd take it to the edges just like this.... which is what happens with this UI on a smaller screen.

That's the sort of job a tablet screen is good for, which is the kind of job that material design is good for, but it's not good for desktops... at least, if you can read without difficulty.

Thank you for sharing your feedback here @pallaswept. It helps us think about how we introduce UX changes across GitHub. We take in a wide range of options for changes and try to find what will work best for most folks across device types, regions, abilities, and more.
We also rely on our design system Primer which ensures we are using shared interactions and components across GitHub.

If you need to TL;DR, just read the last sentence.

Primer needs work. It needs to step out of Google's shadow.

4K is 3840px and the widest display you allow for is 1400. The layout foundations are very obviously 'inspired by' (if not a direct copy of) Material Design, which is your competitor's model designed for their primary means of farming data from their users, to sell to their customers - the mobile phone... It's a design model that didn't even allow for 1080p landscape aspect until a few years ago....

That makes sense if you're following Primer's intention of providing an experience that is familiar to the users, since practically everybody uses a mobile phone - but it doesn't make sense if you're measuring the display, and it doesn't make sense if you intend to innovate to provide the optimal experience.

It's like... running a restaurant, and offering the user a big mac because they know it and you know they like it, when you have a Michelin star chef in your kitchen with a fresh slab of wagyu. Microsoft have a long history of borrowing ideas from others and improving on them and making something that stands out, but this isn't taking from them and improving upon it, this is just following Google like sheep. You guys can do better than this.

Github is a software development platform and by far more software development happens on desktops, but your UI/UX design model is phone centric - because you want to copy an artefact of your competitor's income stream, to leverage (and thus, reinforce) the users' familiarity with it. Think that over.

I see now that the "Give feedback" link in the feature preview popup takes me to an older discussion about these changes, and surprise, all the problems I'm seeing were raised by others back in October and were shipped anyway. I was too taken aback by losing the most important elements on the page to immediately notice that branch names are also being truncated in spite of ample whitespace, but now that I look again, that's still a problem too.

all the problems I'm seeing were raised by others back in October and were shipped anyway.

🤦
Is all this feedback falling on deaf ears @patrick-knight ?

Edit: Now that you mention it, Dan, the excessive whitespace I mentioned above, was also pointed out back then.

Thanks for the callout on the preview bug @DanH42. We'll get that fixed soon, and I appreciate your feedback about these changes in general.

branches page is my starting point for every PR I create and also how I keep track of their status,

Thanks for sharing this point specifically. It is really helpful to hear about different workflows.

As far as the previous feedback, there are things still inflight, like clicking the background to close the modal, that we're working with our design system team to resolve. Other areas, like decisions around whitespace, are design directions GitHub-wide to ensure consistency across experiences.

decisions around whitespace, are design directions GitHub-wide to ensure consistency across experiences.

You wouldn't want your experience of driving a farm tractor and driving a racecar, to be 'consistent' with each other, right? Inconsistency across computing experiences is intentional. It's built into the hardware; the form factors, the input devices, the aspect ratios, and so on - all very intentionally inconsistent. That's why people are complaining about the 'consistent experience'. Those words sound nice, but if you actually stop and think about it, they aren't desirable. Just like you'd be disappointed if your racecar drove like a tractor, or your tractor pulled like a racecar.

....But I feel like that was an elaborate "yes" to my question.

Truncating the branch names when there's so much empty space on the page is just ridiculous - it takes much more effort to scan the branches if they have long names. In my case I even have several that only differ slightly at the end of the name, so I can't distinguish them - I have to hover each one individually.

And replacing the PR status from clearly visible coloured buttons to barely noticeable icons is not great either. Before I was easily able to see what needs to be merged. Now it involves a lot of staring and is so much prone to missing something.

Are there specific area that are not working for you?

Hey @icp1994 that future iterations for us, so not ready for release at this point.

Yeah the warning is present for open PRs:

I see. I think people will find Check status and Pull request in context of upstream PRs quite useful for forked repos when it lands eventually.

@patrick-knight not sure if it's a regression but when I clicked on the trash icon

it deleted the branch without prompting me about the open PR

Appreciate the feedback! The comment badges have been re-added.

@patrick-knight : would it be possible to clarify, please?

There are a few different experiences across GitHub where we show the commit title and based on context they might be resized. But the overall commit title length has not changed on the commits page since these changes rolled out.

This is an interesting automatic reply to see on an official discussion...

But I digress. Is there any chance the new README/LICENSE/etc tabs will also include CONTRIBUTING.md? This was previously requested by more than one person.