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.
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.
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.
I don't expect companies to take on my feedback. I do expect them not to treat it like it's a joke.
You destroyed much of the trust I had. Will you roll this back and reconsider after talking more of your user base?
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!
Here's my input. Maybe it's useful? I don't know.
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'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!
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
I changed 2 things and that's the result:
https://i.imgur.com/RU0rsAO.png
Disable:
`border-top: 0 !important;`
from .border-top-0
Set this class to this value:
.color-blue-3 { color: rgba(3,47,98,.5) }
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.
SCRIPT1053: Const must be initialized
SCRIPT1014: Invalid character
SCRIPT1010: Expected identifier
SCRIPT1003: Expected ':'
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.
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.
I have to use CSS to remove empty gaps on both sides.
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!! :)
Google did us a favor and made an awesome Golang client library specific to GitHub
If there isn't you've done a tremendously bad execution job and no testing.
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.
They be building Norman Layouts at GitHub
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.)
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.
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.
The number of broken master branches I’ve seen on Github is astounding. So I find the CI status indicator to be very useful.
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.
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.
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.
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.
If they're pushing for that, then keeping the README below the file list seems counterproductive.
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.
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.
Overall, seems like change for the sake of change. Boo.
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.