Hacker News new | past | comments | ask | show | jobs | submit login

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 short-hash is the last thing I care about. You cannot see if your default branch has passed CI/status checks now. Those things should be first class citizens, that's why we put status badges all at the top of our readmes to make that info more visible with what we have.

It follows the trend of designing with lower information density. This trend IMO is not appropriate for developer tools.

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.

Also there's font-size party happening on the home's right sidebar. 16px, 14px, 12px in a rapid succession.

Meanwhile, on Pull Requests' right side bar everything is rendered in 12px size.

Just to be clear, 12px is equivalent of 9pt. That's fairly small on screen. For comparison the README body text is rendered in 16px, which is equivalent of 12pt.

By the way, HN body text is 13.33px, about 10pt.

Weird design choices like this are why I've been setting minimum font sizes in my browser since the day the feature was added. It's a life saver, especially on high-resolution displays.

How do you do that?

Not only that but it also feels like everything is floating left. (Which it is but when there's nothing on the right scrolling down it looks out of place.)

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

Agreed - the right column is a waste of screen space and makes the reading experience generally unpleasant.

I have a light sensitivity condition; large patches of white really hurt to look at for any real amount of time. Please consider implementing an optional dark variant in the vein of https://github.com/StylishThemes/GitHub-Dark as an option.

It's coming.

Amazing! Been waiting for it for a long time. I spend a lot of time on github!

Multiple dark themes, if possible: Solarized Grey dark *Pitch dark (also swap the roles of blue and yellow, except for the yellow light seen in the CI)

A Solarized-light style one (similar to HN's background) would also be nice. Text becomes blurred for me in dark mode, and the white backgrounds are too bright.

Cant wait!

Would have been nice that it was deployed as the same time as a new layout that's completely harsh on the eyes.

The density has increased with things that aren't useful.

You're browsing the file listing page (<> Code tab) but it now has a bunch of extraneous stuff on the right hand side (Did you know that this repository has 0.5% Perl code??). Also the most prominent bit is the bold #105 in the commit message - who cares about the handcrafted comment, the important thing is the Github specific pull request number.

Agreed about the right column. Distracting and leaves much less room for what matters, typically a README.

Absolutely spot on.

If only there was a "Feature preview" option where you could ask users and the community what they think about design changes before they go live. Oh wait you have that. You just rolled it out for a couple of weeks basically to see if there were any showstopper bugs before you went live.

I don't expect companies to take on my feedback. I do expect them not to treat it like it's a joke.

To follow on, many of us felt this was rushed through and that our feedback was not heard. You can sense the frustration in the parent to this comment.

You destroyed much of the trust I had. Will you roll this back and reconsider after talking more of your user base?

Agreed, I gave feedback but no use. I am not wasting my time when they’re not going to even bother listening to my feedback. I am out of the previews, not doing your QA for free.

I'd urge you to keep accessibility in mind. I have a bit of an issue with processing visual information, and the fact that the files don't have any borders on them now makes it really difficult for me to process which file has which status. Having toggleable borders (horizontally and vertically) would be a huge improvement in terms of accessibility.

It'd also be nice if you could have the bar at the side up top, or shrink it a lot. It takes up a quarter of the screen space plus padding and margin. For reading README.md files and Awesome Lists, it's extremely intrusive.

Alternatively, you could have the README.md below the longer element of the new "sidebar" and the file list, so that it can take up the whole width of the screen.

I hope you read this!

Can I ask why did you people bring those design changes - this one and the last instalment as well? Was there some real need, some market research behind it, or just an itch to do something? To be honest both these iterations feel like trying to fix something that's not even broken.

It's great to read this comment - it's always nice to know that community suggestions aren't just cast into the void

Yes, I was really impressed to be contacted by a genuine developer with sensible questions when I gave feedback on the GitHub Android app beta a little while back (funnily enough, given other comments here, my concern was it had simplified away something I found useful!)

Reminds me of when HN added the [-] and everybody complained it was on the wrong side but they couldn’t be * to fix it.

I love that it's on the right. It means when on mobile, I don't accidentally upvote something that I meant to collapse.

that's because HN on mobile is bad, not because it's good UI

The up / downvote arrows are too close together. Always have to pinch + zoom to upvote.

What about the contrast reduction issues that this design change incurs. Did you think about those of us who have poorer vision? What are you going to do to make GitHub more readable for those with disabilities again?

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.


The old layout wasted more space on the sides. But I agree the new layout's top bar is misaligned.

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.

I just want to echo what others are saying about the sidebar on the right. It feels like it's taking up way too much real estate without offering much value. The most important information feels constricted to me.

I'm sure as I get use to the new design I'll be able to navigate without much issue, but still figured it's good to share with ya.

Thanks for gathering feedback!

Seems like it might be continued ignoring of our feedback.

Nat drive-by commented on a non critical comment. Did not address our main concerns. Did not say anything like "let us take all this in and come back with something articulate" either...

Definitely feel like Nat and GitHub are actively ignoring is at this point

Very curious here: Can you tell us what the user interviews indicated, what were the personas and problem to solve, and successes/challenges usability tests uncovered?

I think new UI is eyes exhausting at nights...

I changed 2 things and that's the result:



`border-top: 0 !important;`

from .border-top-0

Set this class to this value:

.color-blue-3 { color: rgba(3,47,98,.5) }

Change is bad unless it is great.

Don't make changes just because your designers need something to do. When you make design changes your customers must immediately love it, if not it is a bad change. When it comes to design, there is no such thing as a "good change", there are only bad changes (the default) and great changes.

I agree with this. Taking on a "UI overhaul" of something folks don't see as a problem is just inviting them to try other tools. A lot of devs love using Github already - why up-end them?

In what ways do you consider the new design to be better?

Little late to the party here but I am a heavy user of GitHub both personally and at work, and these recent changes have made it much less enjoyable, usable, and efficient.

I feel as though they were driven by some need to refresh the look of GitHub, but not by the need of the users. And this I think is the biggest mistake here.

If you have roughly 40,000,000 active monthly users — how many of those do these design changes serve? And how do they serve them?

That's what I'd be asking now if I was on your team.

There are bugs in IE 11 (which has 5.88% usage on desktop according to NetMarketshare and is still supported by MS) - dropdown buttons and other interactions do not work due to JS errors:

    SCRIPT1053: Const must be initialized
    SCRIPT1014: Invalid character
    SCRIPT1010: Expected identifier
    SCRIPT1003: Expected ':'
Please fix them.

GitHub dropped support for IE in July 2018: https://twitter.com/michlbrmly/status/981855020948877312

How much of those IE users are also users of GitHub?

Shipping more modern EcmaScript versions than what's supported by IE has lots of advantages for users whose browsers can support it, so I'd hate it if the IE support came with the expense of everyone else's experience. There are ways to serve different JS bundles for different browsers, of course, but that comes with a maintenance cost for them.

Weird though that some buttons wouldn't work at all, because at least most of the basic functionality seems to work fine with JS disabled even. Maybe they should just disable JavaScript altogether for IE and it'd work better. That should be easy to implement too.

Wow, I think you didn't get enough credit here for replying to this thread! Kudos to you!

I personally like some aspects of it and dislike some other, but nothing major in my opinion. What I can say is that only recently I started using the 'Projects' feature and it's really awesome!

Amazing work, and assuming you're the real 'natfriedman' it's amazing you answered!! :)

Thanks for taking this into consideration. You can move stuff around for years and it wouldn't bother me. Lowering that bit of information though is a big pain.

Started a thread on twitter to see if we can get more questions answered or an answer to when we might



Why aren't you doing A/B?

What would be the evaluation metric? Certainly measures like "engagement" could give exactly the opposite signals - hide everything behind more clicks and you'll get a lot more clicks!

My clicks will be going away

Google did us a favor and made an awesome Golang client library specific to GitHub


Should Github ever decided to do a/b testing I hope it's done either per repo or per organisation rather than per user. The last thing I want is members of my team having different views of our work.

I had access to the design by flipping a switch under the 'feature preview' section of my profile menu. Had a little notification blob prompting me to see what was in there.

> pro information density

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

> Also – I don't think there is a principle of lowering information density at work here.

If there isn't you've done a tremendously bad execution job and no testing.

Bring back the old Github! The new look is a mess.

Wow, already fixed! That's fantastic :)

Nothing is fixed

I find it much more difficult now to line up filename and last modified time in the file browser.

And I agree on the low density. Plus it now looks like a children's toy, not like a work tool. A while ago, there was an article on HN about kawaii cuteness culture sneaking into everything. It appears that has happened here.

Ya I noticed the file list no longer has borders between rows. This makes it harder to scan.

The Kawaiization of Product Design - 33 days ago:


I started rereading The Design of Everyday Things by Don Norman last night.

They be building Norman Layouts at GitHub

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

It's not so clear cut. Most places I've worked, we don't build artifacts (docker images, whatever) until there's a merge to master or a tag has been pushed. This automatically means that even though your tests remain green, you still want the status check for the stuff that isn't relevant inside a PR.

For us, if the status is red in master, it doesn't mean the code is wrong, it means something went wrong in the deploy pipeline.

> Most places I've worked, we don't build artifacts (docker images, whatever) until there's a merge

The projects I've worked on have used a bot for merges, and that bot handles building artifacts. In some cases, there's a lighter CI for "this looks reasonable", and then the full CI (including building artifacts and running more extensive test suites on every supported platform) runs before merging.

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

The number of broken master branches I’ve seen on Github is astounding. So I find the CI status indicator to be very useful.

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

Broken master is inevitable in a large enough project. Really what you want is to be able quickly fix a broken master.

By all means keep a perfect master if you have a toy project but once things have several developers hacking on a project with multiple artifacts and hundreds of thousands or millions of lines of code then you need to accept a broken master.

> once things have several developers hacking on a project with multiple artifacts and hundreds of thousands or millions of lines of code

That's exactly the case where you need more strictness about passing tests and CI before getting merged.

It amazes me when I come across a major project where the latest committed version often doesn't even build, let alone pass tests.

Yes, there are absolutely cases where you can't test everything; for instance, if you have complex combinatorial configurations and one obscure configuration fails. But that's a far cry from "inevitable in a large enough project". On the contrary, it's more important to avoid in a larger project.

Wow. I don't get it. It's still very similar just a bit worse all the way around.

That was my initial thought too. But I discarded it as conservatism, and giving it a try.

To be fair, likely there's not much difference. One good thing I noticed is now there is a link to the the latest release.

> the single worst change is that you can't see the latest commit status from the repo screen

Maybe they are trying to push towards using badges/shields inside the README [1]. But yeah, I agree that this makes monitoring repo health less convenient.

[1] https://shields.io/category/build

> Maybe they are trying to push towards using badges/shields inside the README

If they're pushing for that, then keeping the README below the file list seems counterproductive.

I’d second this. In fact, I think the README should be the first thing (potentially in collapsible form so you can easily see the file list without scrolling too much).

Intuitively, I’d bet most people landing on the front page of a repo are consumers of the library looking for a README with info on how to get started or where to look for information on how to get started. Again, this is only intuition—no data to back it up. Project maintainers are most likely interacting with the issues and PR sections or code on the command line.

I personally liked this change. Even if it is the MS MO embrace extend extinguish.

If I want to read your readme ill click on your readme. If im visiting your github page I want to read your code.

Eee, theyre downplaying the focus on cross platform friendly md files showing repo info, instead they want you to use the newly more prominent side bar that is wholy only available on github.

There’s also the issue of the huge amount of white space within the files table. And the lack of centre alignment of the table.

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

Also you used to be able to hover over a commit and see the full commit message. That doesn't seem to work anymore.

Overall, seems like change for the sake of change. Boo.

That absolutely does still work. Used it a few times today.

Definitely does not work for me (firefox 77.0.1 on linux).

100%. This was the first thing out of my fingers today. I want to fully use github actions. Status is huge and getting to a build is a must.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact