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.