How did the performance of GitHub become so slow in the first place? It didn't used to be this bad years ago.

> loading a cross repo issue is a much slower experience

Why not solve the real problem instead of putting in a janky workaround?

At risk of being cliche, it seems like you guys could benefit from the 5 Whys approach here: "Why is loading a cross repo issue slow?" and iterate until you discover the root cause, and fix that.

I suspect fixing the root cause is going to be a lot less glorious career-wise than implementing a UX change that is easier to tout at review time (well maybe not so much after this debacle).

> update - this change has been reverted and the previous behaviour is back

was an on-call engineer paged for this on the weekend just to roll a revert instead of waiting until Monday?

To be honest GitHub should have like a switch for "preview stuff adopter" where you guys could give any benefits for it (maybe more copilot usage?). This way you can test with a specific public, using metrics and feedback, while testing and people could comment more about it.

Can you elaborate? The header meaning the top part of the page? I just checked on a recent repo I visited and it has the usual banner (which would stay the same), the repo path, some links, and some stats. Considering every page navigation would likely pull which links and stats are shown, why is this a delta to go to another repo and why are presumably 3 database entries (possible links, stars, forks) so slow?

They should also order the comments in order of recency top to bottom so you have to read the page in reverse.

I don't think there is such a thing as perfect UX and I'm not asking for it. I just want them to stop making it worse.

Seriously tho, why isn't this something that a browser can do? Why can't I just split a tab and say all links from the left tab open in the right? Why not be able to scroll through history as a list of such panes like a smalltalk browser or file explorer on a mac? Maybe even a history tree, able to be forked with a click or two. Tree-style tabs are a baby step toward that, but I'm not seeing much interest out there in actually learning how to run.

It's precisely because they're so big that they can afford to overhire lots of designers, which then obviously need to justify their employment by continually changing things. This isn't a problem with small and tiny companies where "UX designer" might not even be a separate job but the responsibility of someone who will care only enough to make something that works and then leave well enough alone.

It gets increasingly difficult to design a website properly when you have different teams with different goals each competing to put their little feature front-and-centre, leading to a hacky job on top of a hacky job on top of a hacky job, which in turn hurts the performance until one day someone finally decides to re-think the whole thing from scratch and pisses off >50% of its users in the process that are used to the mess.

It's way easier to nail the UX when you're still in the dozens-of-employees stage of growth and offer like five features in total.

> It’s always been interesting to me that multi-million and even billion dollar tech companies don’t have perfect websites in terms of UX.

This, but for online shops, especially clothing. Horrendously buggy, laggy, with broken navigation (especially when navigating back), filters that don't work on > 95% of online stores. Why they wouldn't fix their primary (or at the very least highest margin) income stream is beyond me, but I've had to abandon so many shopping carts just because the checkout flow is literally broken.

The larger the company, the more it will be designed according to internal incentives, and less by people actually using their own product.

As someone who has built a lot of greenfield UIs while also maintaining old ones (13+ years old SaaS), I recently set up LinkedIn ads and realized the UX is abysmal considering it’s something they’re actually trying to make money from. Maybe—just maybe-I’ve seen such poor UX in a free web app that lacks a maintenance budget. The only reasonable explanation I can come up with is they have a lot of silos within the ad portion of their platform, and each team works on their little corner and no one tries to work with it end to end. Since it’s LinkedIn, this is inexcusable. You go and try to make an ad campaign and then an ad set within it containing some ads, and then come back to it a week later and try to find all these entities you created. You may land on one and take a very long time gritting your teeth and praying for a way click around until you can find another one. What‘s the net drain on worldwide GDP caused by the time-wasting UX of this component of LinkedIn?!

UX is really, really hard - and for some reason still not fully respected as a discipline.

> It’s like these products that are in a way some of the most valuable products in the planet, are given a junior web dev and a “UX designer” who really doesn’t know anything about UX.

What you pay attention to grows. And company's pay attention to those things that move the needle on revenue. For many successful platforms UX doesn't move the needle much anymore (if it ever did). LinkedIn has effectively won their space and a clunky UI isn't going to show up in the numbers.

LinkedIn might have amazing designers on staff, but if leadership isn't prioritizing updates and fixes it won't happen. And leadership won't prioritize it until the problem shows up in the numbers.

Companies are in it to extract as much value as possible for the least spend. Inside a bigco tech company nothing get engineering time allocated unless there is a monetary ROI attached. Which is why basic usability is neglected while features to sell you things are worked on constantly.

It's more like no one cares about UX. People keep using the product and they keep printing. Why invest in a UX researcher or designer?

The other day I was visiting intercom support tool

I realized it has morphed into completely unusable tool with so many features that i don't even know what to do inside it anymore.

Same pattern I saw in many other tools and product. As time passes software becomes more and more complex, then a new one comes which simplifies something and then it also morphs into some enterprise behemoth

I would argue that senior engineers, of which I am one, are more of the problem than junior. We build fancy custom components when we should be using the existing ones.

Yes, the (senior) product and design people are part of the problem too.

We need to build simpler software that works.

> that multi-million and even billion dollar tech companies don’t have perfect websites in terms of UX

I would have thought it'd be the opposite.

It implies have hundreds of teams and UI / UX often is "scaled" in weird ways where everyone does their own thing and becomes a giant mess.

Everything is "correct" when you slice it enough. So from team A's perspective this might be a gain. When you are a part of a team you only see and own this part. That's your KPI.

Unless there's real and working governance (often very very hard) then it's not happening. To get that governance you need company direction and company buy-in that stops managers trying to push new features fast to infinity.

Something about software engineering has gone wrong nobody thinks much about UX they blindly try to give functionality to the business/ customer requesting it but without considering whats already available and how to maintain status quo as much as possible. But theres also room to make things simple and intuitive.

Google released an AI music studio and their primary UI is literally an AI chat window. I absolutely hate UIs like that.

The metric for perfect is

-Does it drive more people to the app -Does it maximize time spent on the site -etc

Your idea of perfect is very different than the one LinkedIn is using

Recently I was buying furniture and it quickly became obvious that "Can I actually browse their catalogue?" is a requirement that really narrows down the search.

They make tens of billions, elsewhere to not even care about tiny UX issues like this.

At this point, it will stay broken because the amount of people complaining are not paying but are a tiny amount of people that will end up continuing to live with it.

So it won't be fixed.

This was exactly my thought. It breaks every bit of intuition I have using a browser, and makes pages run even slower.

And GitLab, too!

When you click the link it will not navigate to a new page, but instead open some kind of pop-up window with the other issue. I have been very annoyed by this behavior for the last couple of days.

This is not about new tabs. It refers to an in-page panel that displays the content of the linked issue instead of navigating to it.

Idk, it almost seem a workaround for slow/broken go-back? If go-back is fast and state preserving, it's basically a fullscreen modal.

All(?) browser open links in a new tab when middle-clicked?

Why would they care to empower competitors?

I was responsible for this going out. The goal was to provide a more consistent user experience in that what happens when you click an issue would be the same in more places where we use the issue viewer (sub-issues on an issue, our dedicated issues dashboard (https://github.com/issues), GitHub Projects, and others). Like you mentioned, you also wouldn't lose your place when clicking an issue reference when reading a discussion. There were some performance improvements that came with the change too. It was well intentioned, but we hear you, and thanks for the feedback. We missed the mark on this one and it's been rolled back.

There's already something like this for GitHub: https://github.com/refined-github/refined-github

> Utterly insane that this went through QA.

Big assumption you're making there.

Tay.ai (Microsoft's infamous chatbot) and copilot are too busy vibe coding GitHub into the ground to look at the issue. There is no CEO of GitHub anymore to respond, which means no-one cares anymore.

Unfortunately GitHub, err Microsoft, stopped listening a long time ago. From the feed to text contrast to many more issues, their community feedback repo has become a place where complaints go to die.

> A/B testing showed github that this might be preferable

A/B testing can’t measure preference, only interaction.

I guarantee you it's not preferable to the majority of github users.

Except there was a different comment from someone that actually knew how it came around, and it was an ugly performance workaround.

Can you actually show us this research and a/b testing?