Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Thoughts on new GitHub layout?

news.ycombinator.com

Post reply on HN
Print view View original

171–180 of 590 posts

Re: Ask HN: Thoughts on new GitHub layout?

#171

Post by eyerony »

atarian wrote: post #109

It looks OK, but I hate how the header is now justified to the edges instead of being centered.

Oh is that what it is? I was trying to figure out why it looked so bad when not zoomed uncomfortably far "in", when I didn't recall that ever being a problem before. I think that's it.

Ugh now I can't un-see how much farther it is to mouse from the repo "body" to menu items (including those associated with the repo, which are now, confusingly, disconnected from it visually) now. Thanks for that.

Re: Ask HN: Thoughts on new GitHub layout?

#172

Post by Kyrio »

qqii wrote: post #4

Example repository of a project that's invested in using GitHub: https://github.com/NixOS/nixpkgs Discussion on /r/github: https://www.reddit.com/r/github/comments/hei81f/ Personally I think it's an improvement on mobile - finally the entire README is readable by default. That being said was there any warning/reasoning behind the change? I cannot find any announcements.

It's indeed much better on mobile, since the old design not only hid most of the README, but also lacked many useful indicators from the desktop version (languages, releases, etc.)

The thing is, they just released an excellent app, which was seemingly meant to solve the problem of browsing GitHub on mobile. It's a bit surprising that this design, by many aspects, seems targeted towards mobile users and is already displaying more useful info than the app.

Re: Ask HN: Thoughts on new GitHub layout?

#173

Post by leegraham »

t0astbread wrote: post #138
Sachaniman wrote: post #18

Sign up for the developer feature previews, so you can give feedback to these changes before they're published. I gave some negative feedback about it earlier regarding this change, but it seems I might have been a part of the minority.

I gave some feedback on this as well but unfortunately I only saw the preview like, two days ago. Have I just missed it or did they not roll this preview out earlier?

I got it on 19th June (I remember because it was the day GitHub went down). I left feedback, but it feels like it would've been a foregone conclusion at that point.

Re: Ask HN: Thoughts on new GitHub layout?

#174

Post by blueline »

ljm wrote: 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…

yep. this and the change to the file browsing, where the lines that delineated files/folders are now gone, causing me accidental misclicks of the wrong file, are two very glaring annoyances. everything else i feel neutral on

Re: Ask HN: Thoughts on new GitHub layout?

#175

Post by eyerony »

Nextgrid wrote: post #168
verdverm wrote: post #38

Earlier quoted context omitted.

So much of modern design seems to be more about / for the designers than the users or UX. Maybe they need a good introspective period in their art, or some psychology classes?

I don't understand the appeal in this for the designers either. Back in the old days (~2010s) every UI had some personality and very intricate details that the designer would be proud of and that will differentiate them from the competition. Nowadays it's the same flat, white and empty UIs everywhere - there is no significant difference. Would a designer really be doing their personal brand a favour by putting one of…

The appeal is that they need something on-trend to put in their portfolios for career advancement. It's their version of résumé-driven development. Project managers have similar incentives (screenshots are very powerful, in many settings) so at least don't stop them, if not actually encouraging them.

Re: Ask HN: Thoughts on new GitHub layout?

#177

Post by tom_ »

MikusR wrote: post #129
driverdan wrote: post #114

Earlier quoted context omitted.

There's are large release section at the top of the right column. It's given more real estate now than the simple link that was there before.

Previously it was at the top in the same row as Code, Issues etc. Now without scrolling it is at the bottom right corner.

It was a sub-heading in the Code section. See, e.g., https://web.archive.org/web/20200320205539/https://github.co...

Re: Ask HN: Thoughts on new GitHub layout?

#178

Post by JoshTriplett »

ljm wrote: 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…

> 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.

Omitting the commit message is a net improvement to me; I've found that the commit message of the random commit that happens to be at top of tree is completely unhelpful for someone browsing the repository, and especially someone new to the project.

However, showing the status indicator inline does indeed seem like a good idea.

That said...

> You cannot see if your default branch has passed CI/status checks now.

If it hasn't passed CI and status checks, it shouldn't be in your default branch.

(There are cases where periodic status checks may get re-run after merging, such as checking if your default branch builds with more recent versions of software than it was originally tested with. But the normal CI and status checks should run before merging.)

Post reply on HN