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