Why are some pages not reflected in the tab name?

When I go to the Play page the browser tab name changes to Play.

When I go to the Puzzles page the browser tab name changes to Puzzle.

But for some pages the tab name doesn’t change and stays at whatever tab name it was beforehand.

For example, the setting page and SGF library are some of them.

I tend to keep many tabs open so I find it inconvenient that I can’t tell what it is from the tab name.

2 Likes

I agree, things like this can easily be fixed in minutes, not delayed by months. Inconveniences like this add up over time and create an unpleasant user experience.

You keep saying that, and yet you haven’t demonstrated it yet.

If it is so easy, why not make this your “small PR” that gets you accustomed to contributing.

If you are “too busy” does it perhaps occur to you that everyone else is similarly busy with other things?

FWIW the usual contributors (myself included) are totally aware of the effect of inconveniences like this. Do you think you are telling us something new?

BUT we are also apparently more aware of the higher priority things, and the actual cost of changing anything.

It’d be great for you to get involved and discover some of these things for yourself, so you could make better educated suggestions that are more likely to be helpful.

5 Likes

I usually agree with you, but I disagree here. These small changes are only hard because it’s an open-source project that I had no hand in choosing the frameworks and code conventions for, and half the files are bloated with 1000+ lines of undocumented code. I don’t see why I need to clean up after someone else’s mess.

Done (updated window title for 5 pages and submitted a pull request). Since you sent me to do this work, I’m going to be blunt – this codebase is a mess. For one, there’s a mix of React class components and functional components. And why is the AppLayout responsible for checking whether the user’s name is too long? As for the problem in this thread, currently if a user goes from Rating Calculator to the Joseki page, for example, the window title would still say “Rating Calculator”:

The underlying problem is that there’s no performant (not using useLayoutEffect which is synchronous and blocks page load), open-source-friendly way for React Router v6 to have a default window title set. If this was my codebase, I could consider using a different router from the very start, whether it’s NextJS or React Router v7 which has a built-in solution via MetaFunction export or something else.

Feedback about the state of the codebase is meaningless.

We all have ideas for how we’d refactor, recode, do it better next time.

It’s easy to criticise someone else’s long-term project, especially without any appreciation for the history, rationale or current priorities.

PRs do the talking: if you spot an improvement, it’s only meaningful in a PR.

edit: some feedback is great

Actually we chat all the time about what could do with improvement, and when - in the dev chat.

Contributors give their feedback in that conversation - it’s the appropriate place.

Thanks for the PR about window titles. Kudos to you for getting this far - most “complainers” don’t!

It’s waiting for your fixes as per AI review.

It’d also be better if it came with an e2e test .

4 Likes

hell no i’m not writing an e2e test for changing some window titles. The documentation for it is gibberish and it wasn’t even mentioned in the contribution guide. You don’t have to give me Meijin for this one. The whole point was to prove that this was easy to fix. In my project it would take 30 seconds. The only reason I took longer than a few minutes for this PR is because I was researching how to fix the problem from the root cause – to ensure all pages/routes in the future have a default page title and avoid the problem in my provided screenshot. I found the issue was with React Router v6 and I have no interest in spending more time to fix it.

I still have no appreciation for the frontend of OGS and never will. Look at the UI design I came up with for the Play page this week with zero graphic design experience ( UI update v0.3: Home page / play page rework ) that clearly works better than what any of your past designers came up with in 10 or 15? years. I’d rather make my own Go server than constantly submit PRs to this broken codebase. I know for a fact I can do a better job on the frontend – only the backend with setting up multiple versions of KataGo and serving APIs for user-hosted bots are things I would need to study.

BTW, one of the fixes the AI review requested could be automatically handled by an ESLint rule or plugin (merging import statements from the same package/module). That’s another example of extra work I wouldn’t have to do in my own codebase.

Typically I’d have expected a “best practice” contributor to ask “where to add the test” :woman_shrugging:

We should definitely add “adding a test” to “Contributing” though, you are right.

That’d be an easy PR :smiley:

You could have included that in your PR :wink:

Anyhow thanks for the contribution, I imagine it’l get merged in due course.

1 Like

2 Likes

10 Likes

Regardless of how rudely I gave my opinions because I lost my patience, the reality is I told you exactly what’s holding back the OGS frontend. Look at my post history on the OGS forums – I’d never been this unfriendly before working on the OGS GitHub. How are you going to attract better designers than me without improving the documentation and development experience? Contributing to OGS - is there a design system? Did this guy not just disappear off the face of the earth after touching your codebase for less than a week?

Joined
May 17, 2023

Last Post
May 17, 2023

Seen
May 22, 2023

Lucky for about every software company, better designers also happen to be better communicators :slight_smile:

4 Likes

I’m not talking about software companies. If I was paid to do it and my survival depended on it, I could communicate well too. but I haven’t wanted to or needed to work at a software company in a long time. I would turn down a FAANG job offer in a heartbeat. I made a conscious decision to be blunt and not mince any words to reflect the toxic experience that is working on OGS open-source.

Compared to working on my own projects (which have over 100 files across over a dozen packages too), this is like willingly stepping foot into a swamp and walking to the destination instead of riding a car. You could not offer me any amount of money to pretend to be happy working on this.

I would respond, but I fear we’ve completely derailed @Sadaharu 's thread. Open to chatting further in DM (but also happy to leave it here)

Thx for the feedback, I’ve fixed this, updating contribution guide and e2e testing README.

3 Likes

I’m sorry that was your experience.

My experience of your experience was:

  • You started contributing great ideas and enthusiasm about page designs.
  • You started looking at implementing your ideas
  • You started slanging off at the codebase
  • People started pointing out other ways of looking at it, argument ensued, and it descended from there.

I’m can see how this is a toxic experience for you … but it seems self-induced.

While you say your rudeness was “reflecting your toxic experience”, from where I’m sitting the slanging came first.

Unless, of course, “getting started with the codebase on your own” was somehow “toxic” rather than just “more difficult than you expected”?

If “code that you don’t like the look of” is “toxic”, then … this explains why you work alone :slight_smile:

The code is what it is - the only way it will improve is through contributions that improve it.

But all this time, you never (and still haven’t) showed up in dev chat, or asked anyone for help.

We have a nice team of contributors, and it does’t feel at all toxic from within. It seems harsh to call it toxic when in fact you have barely dipped your toe in.

9 Likes

can’t deny – this is all true.

4 Likes

shamisen has absolutely no chill :joy:
I thought I convinced you to sugar coat your criticism in the other thread but I guess not.

Out of curiosity how does that work? You sound like a very young person (no offense), I’d guess sth like 20 years old?

And you say you haven’t worked at a software company in a long time? Did you work at Google from 10 to 15 as VP of engineering and then you retired or what’s your story?

Even if this was your codebase you probably couldn’t have considered using React Router v7 from the very start because the project exists since November 2005 and React Router v7 came out in November 2024. You cannot choose to use software which won’t be available for the next 19 years^^

8 Likes

He is 29 years old per what he said in English chat.

He also said once that he is ‘trying not to get angry at Github’. So perhaps his deeper issue is with how Github works.

I think shamisen doesn’t want to reconcile with the cost of compatibility with others; that’s why he works alone on his ‘projects’. Others might do things in ways that you don’t perceive optimal, but that’s how a team works. You can’t do everything alone, so you have to tolerate how others contribute to the team, and also exchange ideas on how to do things better. Eventually, Teamwork has advantages and disadvantages.

4 Likes

But this isn’t the only way. Different structural decisions built from the ground up such as more aggressive code splitting combined with an enforced subfolder structure, or more talent in the UX and DX (developer experience) departments in the core team that started work on OGS 10+ years ago, could’ve also improved the current codebase. It would’ve helped if the people who ran a Go-related business were also good at Go themselves, like having a background in fitness probably helps with starting a gym business.

The entire “Learn to Play Go” section of the website needs heavy work too. Instead of fixing it through open-source PRs on a legacy codebase, it would be much faster to build my own Go website from the ground up, and that’s exactly what you see other devs doing. How many talented devs have chosen to add much-needed improvements to OGS instead of starting their own website? Even govariants.com could’ve been a page on OGS and probably would’ve gotten more exposure that way – change my mind.

In game design, there’s a distinction between natural, meaningful difficulty and artificial, purposeless difficulty. There is not much difficult about any of these jobs other than sifting through third-party spaghetti code. It’s simply not enjoyable. And we’re ignoring the fact that the other designer who came to work on the OGS forums completely disappeared and lost interest in Go within 5 days of touching the code? This is not only about me. I hope OGS will continue to improve even after I’m gone.

Y’all say there’s much better UI/UX designers than me. Then prove it. I don’t see them in the room right now. There’s plenty of other users besides me who are always complaining about OGS frontend I’ve seen on these forums, Reddit, and elsewhere. Can you shut them up? Nobody other than me has the confidence to say that they can.

The cost is too damn high:

this is funny but React Router v6 also came out in 2021, and the project literally has v7 listed as a dependency – it simply doesn’t use it.

You can’t do everything as a team either. Books typically have one author. There are game devs who worked fully independently. I would pay money to have some of you NOT touch my code, like paying money for a babysitter so you can go to work without being disrupted by kids.