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.
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.
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)..
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.
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.
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.
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.
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.
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!)
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.
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.
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?
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?
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 ':'
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.
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.
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.
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!! :)
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!
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.
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.