Live data from Hacker News

Ask HN: Thoughts on new GitHub layout?

news.ycombinator.com

561–570 of 590 posts

Re: Ask HN: Thoughts on new GitHub layout?

#561
Personally I have noticed some changes, but nothing that impacted my productivity in any significant way, and paid no more attention.

I believe sometimes we tend to overreact to certain changes that have minimal impact on our lives, because of our attachments to the tools. For instance, on HN, we seem to get a sea of "That's it I'm moving to Firefox/GitLab/etc.." comments often when their counterparts change something. Sometimes those reactions seem warranted, and in this case, not really.

Re: Ask HN: Thoughts on new GitHub layout?

#562

Earlier quoted context omitted.

Thanks for the feedback about the latest commit status. This is something we should definitely fix. Also – I don't think there is a principle of lowering information density at work here. I think it's just a design that we will keep iterating. We are pro information density at GitHub.

FWIW, on a 1440p monitor, there's a huge amount of wasted/empty space, which means that the things that the space is used for should be pretty critical or it seems like a colossal waste overall. Here's my input. Maybe it's useful? I don't know. https://imgur.com/a/S9YRBq0

For the "Why don't these line up?" pieces, it looks like the new layout was designed for window width of about 1350 pixels.

When the browser window is that wide (for FF anyway), the whole layout seems to line up well.

When the layout is wider than that (eg full window width), there is unbalanced white space all around.

Re: Ask HN: Thoughts on new GitHub layout?

#563

What do people feel about the code at the top (both old and new) The thing I think I want at the top is the readme. If I'm looking for repos I need to know what it is before I look at the code. If it's a repo I'm working on I'm more likely to look at the code locally then the code on github. When I do look at the code on github it doesn't need to be on the front page for me. https://github.com/username/reponame/code…

BitBucket follows this principle and it’s one of the main reasons I hate using BitBucket. The vast majority of the time I arrive at a git repository is because I want the source.

By "want the source" you mean you want to look at the source via the gitlab website ?

I would interpret "want the source" as "I want to download the source" in which case showing the files is useless. All you need is a "download source" button

Re: Ask HN: Thoughts on new GitHub layout?

#564
Why would I want to be able to see a bunch of meaningless icons for contributors? Why is this being prioritized in one of the highest visual-traffic sections of the layout? Why would I want to see what percentage of the project is in different languages as a high priority piece of information?

Like, 100% agreement with everyone complaining about how the sidebar de-centers the README, agreed, that's awful, but what rubs salt into the wound is the sidebar is full of useless garbage! Both as a contributor of code and as a consumer it's hard to imagine things I'd care about less. Have it in a cute little "info" tab that no one will ever click like all useless information, and keep the landing page of a project for essential information.

Re: Ask HN: Thoughts on new GitHub layout?

#565
post #126

I submitted feedback over it but, aside from the over-reliance on rounded corners, and making pills and buttons hard to separate, the single worst change is that you can't see the latest commit status from the repo screen. Instead, you get the commit hash, and have to click a tiny ellipsis button to get the commit message and the status indicator. When I'm browsing on github and not using git directly, the commit sho…

Thanks for the feedback about the latest commit status. This is something we should definitely fix. Also – I don't think there is a principle of lowering information density at work here. I think it's just a design that we will keep iterating. We are pro information density at GitHub.

> pro information density

I have to use CSS to remove empty gaps on both sides.

Re: Ask HN: Thoughts on new GitHub layout?

#566

Earlier quoted context omitted.

BitBucket follows this principle and it’s one of the main reasons I hate using BitBucket. The vast majority of the time I arrive at a git repository is because I want the source.

By "want the source" you mean you want to look at the source via the gitlab website ? I would interpret "want the source" as "I want to download the source" in which case showing the files is useless. All you need is a "download source" button

The conversation was about viewing the source online vs the README so clearly I meant I want to glance through the source online. There's a few reasons I might be doing this:

- before deciding if I want to clone the repository.

- Or sometimes I might just want to check the hooks of a particular API (eg the outputs of a Terraform module) where there isn't really a need to manually clone the repository just to validate some assumptions.

- Sometimes I might want to quickly verify the code that's on origin master is up-to-date (everyone has committed PRs and merged back into master).

- Sometimes I might just want to validate what code kicked off the CI/CD pipeline.

- Sometimes I might be demoing some changes in the sprint review and rather than spin up another IDE / switch branches / etc I might just open a new tab and walk the team through what has been committed on Github

Also nobody was talking about Gitlab specifically. BitBucket and GitHub were mentioned though.

Re: Ask HN: Thoughts on new GitHub layout?

#567

Earlier quoted context omitted.

Thanks for the feedback about the latest commit status. This is something we should definitely fix. Also – I don't think there is a principle of lowering information density at work here. I think it's just a design that we will keep iterating. We are pro information density at GitHub.

Really hate the second column on the right, which for a long README or documentation does nothing but make it so that there's less room for the text. I frequently use GitHub to store and read notes or to create larger docs, this essentially kills my desire to do any of that and makes me want to move what I have. The information in that column is also extremely low value.

I agree with you on this! The right column is just a waste of horizontal space after the first scroll down, as the information there was on the top previously (it's a few not-quite-important things that are wasting an entire column)..

Re: Ask HN: Thoughts on new GitHub layout?

#568

This is the MacOS 11 thread all over again. Apparently no one on HN has been through a redesign... For those of you complaining, congratulations, you've discovered ~ nostalgia ~ In two weeks you'll inevitably find the old design ugly, and forget GitHub ever looked any other way. In 5 years, each will get another round of improved designs, and there will be a thread on HN full of people complaining about how the new d…

The graphics is better, the layout is not. The could have modernised the old design, instead they changed it to Gitlab.

The side bar is one reason I dont use GitLab.

Re: Ask HN: Thoughts on new GitHub layout?

#569

For me it is a bad and unnecessary rework. Exactly the kind where they break a functional design that was refined for multiple years. And they break it just for a product management/ marketing reason to have 'something new'. Both on desktop and mobile there are a lot of useful info lost and at the same time, low density and a lot of empty space. But in addition there is no coherence. For me, the mobile experience is…

For a fun test, I showed my GF the 2 screenshots. I tried to avoid involuntary giving any clue, and asked her which one, she was thinking was the old interface and the new one. She is not a geek, not in tech, and does not know Github. But, you can bet it, her guess was that the NEW interface was the oldest one, and that the OLD one was the recent rework... That is an interesting test to rule out the fact that we are…

I'm not sure why that rules out the idea that people are averse to design changes. For one thing, it's just one piece of anecdata. For another, just because someone thinks Design A looks newer doesn't mean that they wouldn't prefer to keep using Design B if they were already used to it. Anyway, even if we accept that people are generally averse to changes, that doesn't imply that all criticism of a redesign should be dismissed as aversion to change.
Post reply on HN