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
I have a single major problem with all of their new layouts. They place content at extreme ends of the screen, completely stretched out like a rubber band with No Man's Land in the middle. In this case, the top half is stretched and the bottom half is centred. Completely inconsistent and tiring for your eyes darting around corners of the screen.
I don't know why they think it's good design, it would be nice to know. All of their previews for it squash the window so it looks perfect, like their mockups I assume. Similarly, I have to have a dedicated, half-width window just for GitHub to workaround this.
Just logged into GitHub, freaked out when I saw the redesign, and came straight here to say exactly this. It's unnatural eye movement to look wide for platform navigation, then narrow for README/repository navigation. This is outright bad design.
There was nothing wrong with GitHub's UI before, it was probably the closest thing to "perfect" I'd ever encountered.
Alongside that incredibly irritating "navigate to code definition" popup, it feels GitHub has too many designers with too little to do, so they're desperately scrounging around for things to change to fill their day. Either that, or there's some monetization angle (ala the Reddit redesign) that we haven't seen yet.
This is exactly the same what I'm thinking about: what's the purpose to redesign something which was good and familiar with something which is totally unpleasant. On a large monitor you have to move not only your eyes, but your head from left to right, from top to down just to find the relevant information, which on the old github was on the right place. Too bad there isn't an option to revert to the old design.
It seems to me Github from the Microsoft acquisition is going into a wrong direction.
Genuinely curious here - isn't it better for eyes to move more? Can moving in unnatural way be a good thing considering most of the time they move naturally? Like a sort fo stretching.
I don't mean it's literally bad for your eyes - there may well be benefits to constantly shifting your gaze/focus/etc. I can't comment on that.
I'm talking about "natural" eye movement being a well-known design principle. This means that eyes very naturally follow a Z pattern that doesn't exceed the periphery of your focus. So if you load up a fresh page, your eyes will naturally look top left -> top right -> bottom left -> bottom right, bounded by your standard viewbox (which is about 800px-1200px wide at 96dpi and 1-2ft, the standard distance most people sit from their monitor). So you usually stick your most important information along that pattern. Anything outside this boundary requires an extra "look", which means a slight hesitation/delay on the part of the user. That's not to say the space is unusable, just that you put your most common/important features/information along this flow.
It's also not an ironclad rule, but it does work very well. When I went to the old GitHub, my eyes always followed the same pattern: repository name (top-left, to make sure I was on the right page), account (verifying that I'm logged in), branch, clone/download, then file list or more commonly, the README (bottom-left). It was a very quick, natural way to navigate a random GitHub page.
Now, I literally have to move my head to do this. The weighting also feels completely unbalanced, like there's too much information on the left it's all slanting in one direction.
I believe for eyesight it's important to change focus, i.e. the distance of the object you're looking to. Not sure if just moving your eyes help but looking up from the screen into the distance is certainly good for the eyes.
Ya, I didn't understand this design choice. For a while I've had some custom css which also extends the width of the main content on github as well because I've always found reading some github issues with logs in them challenging.
This is the css I'm running now to fix this, as well as extend the width of the main content. The 1600px is such that when using i3 and having my browser be half the screen it consumes most of the screen space on my 4k monitor.
People have suggested extensions here, which is fine, but Firefox also supports this natively via custom css files that it can load for you on startup. They can be used for both styling Firefox itself and for modifying websites' styling.
https://superuser.com/a/319322/1173126
(be sure to read the comments of that answer too, these days you need to switch a flag in Ff settings to enable this feature)
Agree completely. Feels like a huge step backwards. Maybe usage metrics show most users are using a much smaller window size, but the layout is all over the place on my 27" monitor (2560x1440).
> Maybe usage metrics show most users are using a much smaller window size, but the layout is all over the place on my 27" monitor (2560x1440).
Some of us like to code with git / bitbucket / gitlab side by side with our IDE so we can reference existing issues more directly while writing code. Which reminds me I need a better screen resolution... 1080p is so 2016.
This may not work for your specific case, but there are Github issues plugins for various IDEs that will show you the issues list right there in your IDE. I've found them very useful.
I remember this happened before several years ago in a previous redesign where the top menu would just stretch to fill the entire screen. It was later changed to one with a proper max width. I guess they forgot that lesson.
Ha, to me it is an improper max width. My biggest peeve with the GitHub web UI is the squished center pane.
I hate that it centers it with giant gutters wasting over half the width of a 4K monitor, should I choose to maximize a browser window. I'd much rather see everything shifted to the left. I'd even be OK with some soft margin still causing regular README text to wrap at a typical width.
But, if there are long code or raw text lines, or any embedded image or markdown table or other structure that is inherently wide, I want it to overflow and use that extra screen space, not get clipped into this ridiculously narrow bowling lane. That's my instinctual desire and the only reason I would expand the browser to full screen, and it is an utter disappointment to try that and be told, "no space for you."
Sorry but do you use full screen windows on a 4K monitor? I doubt any website is really designed to fill anything more than ~1400 horizontal logical pixels.
I don't usually. But if I do, it's because I just encountered something like super-wide content and I want to make use of that big screen. I don't do it because I'd really like to see someone's opinion about how all content should cram into a narrow viewport and have massive blank margins...
The current 13" Macboook Pro has a hardware resolution of 2560x1600. The screen resolution will be the same if you switch off display scaling. Pretty much everyone using one will have maximised windows because it's physically small.
You really need CSS that accounts for resolution and pixel density these days.
I do. In the age of various resolutions and screen sizes and css frameworks, websites can and should be designed to look reasonable on any number of horizontal logical pixels. If it isn't supposed to be wider than 1400px, that's what css's `max-width` is for.
Its much worse when you are using an ultrawide monitor. Before this change I can just look at the center of the monitor and see all important things, while now I can feel my eyeball moving trying to read everytihng
Yep, I have the exact same issue. I started to use the new design via their beta program, I had to stop after a few days because the content stretches from one side of my screen to the other. I hoped they would fix it before release.
Lots of hate here. I probably don't use GitHub as much as others here, so I can understand that any change adds friction and people are going to hate that. Having said that, I'm comparing using the Wayback Machine:
and I can't find it in me to dislike the changes they've made. They've removed the double repo navbar in favor of just 1. They've added a right-sidebar that shows various info about the repo in general, like what the last release is. Before, I would open the branch/tag list to look at the versions; now, it's plain as day in the sidebar. For the main contributors, I no longer need to go to insights > contributors. They're shown in the sidebar. For the main languages, I no longer need to click on the thin color line. I find that the most common bits of info about a repo that I sought are now displayed in the main repo page. That's an improvement.
I don't understand why people are complaining like it's an absolute disaster. It's not perfect, sure, but this seems to bring significant improvements.
> I don't understand why people are complaining like it's an absolute disaster.
Partly because the ethos of HN is to reward whoever is the best at disagreeing or pointing out flaws in the original post (or in the comment they're replying to). Which is actually kind of useful, because it allows you as a reader to rapidly see both arguments and counterarguments.
Partly because the most impactful and thus most-upvoted commentary is usually going to be whatever is most extreme. Readers love certitude and are bored by nuance. And if you're expressing a grievance to someone who can make a change, outrage is the best method to get them to prioritize your desires, even if you aren't actually outraged.
Partly because it's in our DNA to ignore the good and focus on the bad. Problems tend to jump out at us, whereas benefits are often invisible by comparison, and we easily take them for granted or consider them merely part of the status quo. For example, we live in a world with the magic of cell phones, air travel, personalized advertising, and social media, yet 99% of what you hear about any of these topics is the negative stuff.
The 2013 version by comparison wastes horizontal space while surfacing less information. The contrast is worse and there isn't enough to visually distinguish the four (!) rows of headers. Personally, I also find the navigation box on the right to be weirdly sunken into the page and I think the color scheme has been greatly improved.
The sidebar it had seems to waste too much space, though. It's just 5 links meant for navigation. They'd be better arranged horizontally. I can agree that it's clearer than what we had a few days ago, having only 1 navbar instead of 2, but that's also because it has a lot less features than GitHub has now.
Tangential comment: I just opened the link with the new design on my phone and it was a delight to look at compared to whatever I saw last time. I think the design changes were made keeping in mind smaller screens, which might be what the user data suggested (how am I to know). But I agree with other comments that the top bar content could be aligned with the rest of the content. Stretching it to each end is causing pain.
Most of us don't use GitHub to actually edit code, either. E.g., some projects are using their GitHub repo as the homepage, so I sometimes end up on GitHub on my mobile phone, too.
Might also depend on how you use it. I have no repositories which I maintain on github worth speaking of, I only contribute, so 99% of time I spend in issue/PR views to which I go directly via links from notification emails.
While as pointed out above the decision of making the top navigation bar span the screen is rather unfortunate, the main thing I see is that instead of the smartphone-centered (or whatever reason) design the central part where the comments are shown is now like 50% wider. Which is something I always wanted because I only use this on desktop and usually with the browser full-screen so finally it takes some advantage of the available space.
However the width used also depends on whether the sidebar is there or not which is quite jarring. I.e. in the toplevel file tree view there's a sidebar. But when you then click on a directory the sidebar is gone and the witdh taken by the tree view expands. That's not ideal and just jarring when going back and forth. So for cases like that, it's not merely the fact there was a change which causes friction, it's really the new version which does.
Looking at the repo's main page on a smartphone. The top "box" listing the latest commit message says:
"torvalds committed 20... [...]"
What the ...!!!
I don't know if that was a "streamlining" or has been always like this. Still, makes me wonder at how the UI team prioritizes their efforts.
I don't depend on using GH UI much, so will figure my way in the refaced UI at some point. But I can relate to the sentiment here that the refacing is just the recurring "design tax". Like the cars from 2015 look "so dated".
What's the deal about the round corners? I thought the straight ones were proclaimed the "right way".
That might be an unpopular opinion, but I loved the double repo navbar.
I've discovered the redesign when I wanted to check the latest commits of a git project I haven't cloned yet.
My very first reaction was "oh, there's a CSS issue" while Ctrl+F5 the page, then opening it in a private window to see if one of my extensions somehow broke the page.
Then it took me a full minute to find the link to the git history, while my eyes basically searched in every corner of the screen.
I really loved the old GitHub UI, it made GitHub a better product (in my opinion) than GitLab. And I really didn't like the experience I had while trying the new one.
Aside from the accessibility concerns -- which is honestly inexcusable -- the non-centered repo layout is so strange to me:
All that info that's now in the sidebar is temporary. All of it. I never need to look at a project language more than once.
However, it takes up 100% of the height of the page, so when I'm halfway through a README, the README gets offset by some magical space. The ghost of the 1 paragraph of "language/tags/etc." takes up that space. The README is not centered.
From a design perspective, this layout implies an equal level of hierarchy between the right sidebar and the main content. It implies that they should be referenced side-by-side. But that is just not the case. I want to meet the person who thinks that the document literally entitled "README" (or oh, I don't know, all of the files) is somehow as-or-less important than the tags on a repository -- which are usually just the title copy pasted anyways.
I develop open-source things and I absolutely love to use GitHub. In particular, I've spent a LOT of time reading README's and also writing them. I really think their centered layout should come back.
As a suggestion: Maybe they could shift just the _files list_ over for that sidebar, and have any block content not centered?
Or maybe if there somehow existed a compact way to organize that information. Maybe a horizontal layout because there is only a little bit of text. Something like that.
This is the MacOS 11 thread all over again. Apparently no one on HN has been through a redesign...
For those of you complaining, congratulations, you've discovered ~ nostalgia ~
In two weeks you'll inevitably find the old design ugly, and forget GitHub ever looked any other way.
In 5 years, each will get another round of improved designs, and there will be a thread on HN full of people complaining about how the new design sucks and how 5 years ago was "the good old days."
The new GitHub design is objectively better.
The new MacOS 11 design is objectively better.
"Low information density" means less clutter. You find the information that matters quicker.
Changes to padding/visual separation/sizing/etc. all provide similar context to which information is important, and how items relate.
"Flat design" isn't some trend, flat icons are just easier to quickly recognize, and look far more crisp.
In both threads the degree of negativity is disappointing. Can we not have one or two positive comments on how crisp the new commit graph colors look, how nice the transparent pin dragging interface is, or how the action buttons are more prominent? Not to mention the entire code/README page. The flat rounded corner borders are very clean!
If you really don't like the rounded borders, use wget
Low information density means "less clutter" for somebody new to the interface, but it means "many more steps" to provide all the information that a dense design allows for. So much design fails to take into account human expertise, and our ability to learn complex interfaces. They get the A/B treatment which optimizes for beginners, which always leans towards the simpler, easier design.
This is why we'll never get a better spreadsheet design. In the hands of experts it's already perfect.
If modern UI designers were responsible for building musical instruments, there would be a lot more kazoos and recorders, and a lot fewer cellos and bassoons.
This is also linked to the obsession with constant, never-ending growth.
Bringing in new users is more important than making existing users happier - you just need to keep them happy enough that they won't actually leave. It results in targeting the design towards people that don't use the product (yet) instead of the ones that already do.
Seriously one of my biggest pet peeves. So often I hunt around for the login button, annoyed at being force fed some growth hackers moronic idea of a good interface. It undermines the likely hood that I will "recommend this product to a friend".
Excel today is still cleaner than Excel 2010, and Google Sheets easier to use than both. Most spreadsheet users simply don't need the extra functionality Excel provides, and the few users that do need this use the product enough to have memorized the keyboard shortcuts.
That dumb wall of text simply to show you don’t know what the word “objectively” means.
It’s also telling that so much of this “objective” user experience narrative apparently depends on immediate and gratuitous condescension and hostility towards your users.
You sound like a complete asshole. You’re not better than everyone that disagrees with you. Try to do better.
Engagement rate is measurable. The average time it takes for users to complete the action they're looking for is also measurable. Companies test this stuff, Apple isn't spending millions of dollars to redesign MacOS because Tim Cook is bored. Same goes for the Instagram redesign of a few years ago, or this GitHub redesign, etc.
"less clutter" isn't by itself an objective positive. For example in Japanese culture you might be surprised to find information density is considered a positive. Yes much Japanese aesthetic design is considered to lean to simple but for information presentation higher density is usually considered better.
So this idea that ""Low information density" means less clutter." is objectively better is false.
For me, I'm trying to get work done so my criteria is does the design help me achieve that. For an ad or a piece of art to hang on my wall, a poster, something else having a less cluttered design might be good but it's not so clear it's good for developers who interact with the same UI several times day.
The new design is terrible. If it actually made the website easier to use, then I would be all for it. Unfortunately this is an actual step backwards in functionality and information layout design.
I fundamentally disagree that it was not useful to have at the top. Language/platform is a major factor when choosing whether to evaluate a newly-discovered repository, and the colours for each were very recognisable.
> If you really don't like the rounded borders, use wget
Or just add
* {
border-radius 0 !important;
}
to the page stylesheet, either via userContent.css or a browser extension. Once you know the process, it's extremely easy to hack around web developers' poor decisions if you know a bit of CSS yourself.
I want UI designers to be unoriginal. I wish they were less original. I don't like learning new visual languages every 5 years; I want intuitive interfaces, which mostly means familiar interfaces.
I never thought trendy modern GUI design would get so bad that looking at screenshots of programs running on Windows 98 would feel instantly and overwhelmingly relaxing, like settling into a warm bath, as if parts of my brain being taxed for no reason could finally just chill. Yet, here we are.
One of the arguments by Designers is that they make the UI more approachable - they don't realize that they are biased by their personal aesthetic taste, their friends like the same type of flat sleek modern UI designs, and they like going to minimal galleries, subscribe to itsnotthat and read the colossal blog.
This is a cultural imposition, not something a professional would do. Yet, we have modern designers injecting their personal taste of modernism into UIs, in this case, Github developers are not the average Joe - they are familiar with complexity, highly dense information screens (code!) and don't need any of this non-sense.
Non-designers I've met actually have a better more grounded and functional approach to design, which is what I think design is. Yet the general opinion amongst designers is that the engineers are like Milton from Office Space - they don't understand fashion, current trends and aesthetics.
True story: my dad is confused by basically all technology and all modern user interfaces. The one site he finds usable without assistance? Craigslist.
On the contrary, my parents were never able to use texting on old mobile phones or even 2013-era smartphones. but now they easily are able to do video-calls, voice-calls on today's smartphones and apps.
They are also able to make payments using code scanning and normal transfer through the ease to use interface.
And this is in Myanmar, where we barely had internet for public use 10 years ago.
Craigslist is the epitome of simplicity. It may not be pretty, but it does what it is supposed to and nothing more.
This practice should be applied universally throughout our lives in every field, perhaps except Art where creativity is revered and the avant-garde prevail.
You wouldn't re-write a whole app without a very solid engineering reason.
But site after site re-does their UI without any stated reason.
For companies I've worked for we did new UI designs because they thought it would increase sales, even though it threw out all the sales optimizations we made in the last design. So, it was always a negative for sales.
It's just a big waste of money that upsets users. I understand tiny startups having CEOs that do it out of ignorance. But large organizations should know better.
My theory is that, at these big companies with large, established products, they're just looking for stuff for designers to do.
I mean, you do need designers for whenever you add new features, and you want really great ones for that. But those really great designers want to do something, and there just aren't enough new features to keep them busy.
I mean, I don't dislike the aesthetics of the change, but yeah, I just wonder, "Why?" I agree with the few (what I think are relatively minor) specific issues that have been pointed out where utility has decreased, and I'm finding it difficult to point to any particular change and say, "Yes, this is better than before."
Yep, I think that’s (at least partially) true, even if it’s not explicitly acknowledged in the company. Same with Google and their endless new projects: what else would all those smart engineers do? Support existing projects? Yeah, let’s see how many of them won’t leave to build new things in some startup in a few months. It’s a balancing act on the part of any company employing creative people, I imagine.
I agree, but there's levels to it though. A redesign almost never means learning new visual languages, whatever that means. Low-level elements like hyperlinks will always be presented as underlined text, buttons as boxes with centered text, and so on. Then there's low-level structures such as sidebars, tabs, collapsible menus, etc. which again rarely change and that's a good thing. I wouldn't call it unoriginal but conventional.
A "proper" redesign then becomes finding the right and intuitive structure for the right type of content. Changing the appearance of the same content in the same structure is more of a reskin, which is what we see most of the time. And yes, sadly in the last years the trend has been: low contrast body text against an obligatory bright color for elements/illustrations/icons, rounded corners, and padding everywhere.
I think dark mode was a harbinger of dumbed down UI. Instead of spending time on one good UI, designers and developers were forced to make 2 mediocre ones instead. Plus dark mode is easier if you remove all detail and depth from control elements.
I don’t think they built the dark mode version as an entirely new UI, it’s just some css and a class you toggle on the body, making it perfect would require some elbow grease but it’s not a complex feature really.
It's not a complex feature because most UIs have already been simplified and flattened into oblivion. If buttons and controls still had depth you might need two complete sets of assets. E.g. consider what implementing dark mode in iOS 6 might look like.
That's kind of my whole point. Dark mode features are a symptom of UIs that no longer communicate anything significant with color and shade so just changing color with CSS tweaks doesn't break them.
But designers and developed don't support one UI, or even two. They support anywhere between three (desktop, mobile, tablet) and effectively infinite (all resolutions between and around those + dark modes + apps which use the same data + all different browsers). UIs can't be very good one on platform without either making each platform's UI separate or sacrificing functionality on other platforms.
New GitHub looks alright on low resolutions, but looks kinda awful on big screens. This is the opposite problem old GitHub had.
There isn't a color scheme you can pick where you won't get users asking you for a dark-on-light vs light-on-dark version, whatever is the opposite of whatever color scheme you thought would be one-size-fits-all.
Though you seem to be suggesting that's somehow a bad thing and I'm not sure why. Dark mode is so popular that operating systems have even started supporting a native toggle.
Looks absolutely horrible. I use a laptop as my main dev machine, and all these 16px and 30px paddings that they added everywhere create real tunnel vision experience. I guess people with huge displays don't mind... But I absolutely do.
Looks like another case when a frontend team does something to justify their existence.
But let's look at the positives: the last redesign of that sort helped me to completely migrate away from gmail.
I use a ultra-wide (2560x1080) monitor and it looks terrible [1]. The repository header being "fluid" put the repository name and watch/star/fork buttons so far out of the rest of the repository info, like branch name, commit info etc., that using GitHub maximized feels very weird and tiring.
I get using the whole resolution for the menu bar, since its content is disconnected to the rest of the page content. But having part of the repository info in different "aspects" don't make sense for me
The fluid width makes text harder to read. There's a reason why newspapers print in skinny columns. I wish they would at least let me set a max-width on the body.
I knew there was a reason I prefer skinny column text! I presume the reason is because it's a smaller leap from end-of-line to beginning-of-next, much less likely for your brain to miss.
I don't understand the appeal in this for the designers either. Back in the old days (~2010s) every UI had some personality and very intricate details that the designer would be proud of and that will differentiate them from the competition. Nowadays it's the same flat, white and empty UIs everywhere - there is no significant difference. Would a designer really be doing their personal brand a favour by putting one of these new "designs" on it?
The appeal is that they need something on-trend to put in their portfolios for career advancement. It's their version of résumé-driven development. Project managers have similar incentives (screenshots are very powerful, in many settings) so at least don't stop them, if not actually encouraging them.
Yeah, maybe I am a minority in viewing web pages in 1/2 1080P?
The only screen that is full screen is the code.
But really, I want to look at two windows without issue on the same screen. Is that so much to ask? Can we have better layout on 1/2 1080P screens please?
Like many others, I use Github every day. Changes like this add friction to our workflow.
There better be a damn good reason for these changes, otherwise it's a pointless redesign that looks no better than it did previously while simultaneously adding a slight overhead as users "learn" the new layout.
Does anyone know of an option to revert this update?
My hypothesis is the point is to compete with Jira. That would be MS's biggest competitor in this space, and the changes make it look a whole lot more like that.
I wonder if MS has gone back on their word to leave GitHub to it's own devices...?
I have been unable to find a method to revert. Best option might be to make a bunch of noise. Other than that, it's migration time.
> My hypothesis is the point is to compete with Jira.
When they start making everything drag & droppable at a huge cost to UI latency and bundle size (plus, for some reason, idle resource use), we'll know for sure that's what they're doing.
If competing with Atlassian is the point, then they're going to have to completely revise their licensing model for a start. GHE is _far_ too expensive compared to Atlassian's whole software suite to be any real competition.
I'm curious, what exactly has broken in your workflow? The biggest issue I see is that you are unable to see build status on a commit (above the file list), but otherwise nothing really has changed too much in my opinion.
1. On larger monitors e.g. 4K the menus are on the far left whilst the content is in the middle which makes it far more of an effort to navigate around.
2. Row separators have disappeared so I have to be a lot more deliberate about which file I am clicking now since it's a lot easier to mis-click.
3. Buttons are a mess. You can't distinguish what is a button and what is not e.g. Clone versus the Open Issue label.
4. Clone button is so prominent. I only do this once per repo and yet it's like a giant CTA begging you to click it. Likewise for the folder icons. No need for them to be coloured.
For me it is a bad and unnecessary rework.
Exactly the kind where they break a functional design that was refined for multiple years. And they break it just for a product management/ marketing reason to have 'something new'.
Both on desktop and mobile there are a lot of useful info lost and at the same time, low density and a lot of empty space.
But in addition there is no coherence.
If you had no knowledge, you could think that after was in fact before.
Issues that I can see:
- No part of the readme/description visible anymore.
- Stupidly lost space, like nothing anymore in the top bar to use additional line.
- stars count was smart before by being on the button itself. Now one big empty button and a separate counter.
- for commit, issues, project... Everything was directly visible before. Now, a horizontal scroll is needed. I hate having to horizontally scroll on mobile web. (But maybe it is just me)
For a fun test, I showed my GF the 2 screenshots.
I tried to avoid involuntary giving any clue, and asked her which one, she was thinking was the old interface and the new one.
She is not a geek, not in tech, and does not know Github.
But, you can bet it, her guess was that the NEW interface was the oldest one, and that the OLD one was the recent rework...
That is an interesting test to rule out the fact that we are "adverse" to changes.
I'm not sure why that rules out the idea that people are averse to design changes. For one thing, it's just one piece of anecdata. For another, just because someone thinks Design A looks newer doesn't mean that they wouldn't prefer to keep using Design B if they were already used to it. Anyway, even if we accept that people are generally averse to changes, that doesn't imply that all criticism of a redesign should be dismissed as aversion to change.
That seems like a tradeoff between people discovering a project and people developing that project. People initially discovering a project usually want the README; people developing a project may potentially want either.
I never look at the Code page of projects I work on. I'm always going straight to the pull requests or issues.
I always thought the Code page's intended audience was new people checking out the repo for documentation or to peruse the code (usually after checking out the README).
That is true, I don't really know what the answer is. You could do something like show half code/half readme, with extra code hidden behind a fold.. but I'm sure that would annoy devs working on those additional hidden files.
I'd be happy with a README-first design that had a link to move the README below the code, and that remembered which one you want on top for each repository. (Along with a preference for logged-in users to decide what they want.)
You can also put a Readme in any folder and it will show up the same way. You usually wouldn't want those up top while browsing the files though. So it's also about consistency.
I agree this sucks. If it helps someone else avoid scrolling, I discovered that the "readme" text on the right side (right under the "about" block) is a link to the top of the readme at the bottom.
I'm gonna say it: we need to not dunk on designs by being inconvenienced for like, a second, while we figure out something new. People are way too quick to say something sucks.
Related: I was updating a bunch of dependencies yesterday, and so was going through looking at what's new in a handful where I was behind a major version or more. "Releases" is even harder to find now (it's in the sidebar). I've never understood why it's relegated to a being a sub-item of "code" when it seems to me it should be on the same as information hierarchy level as "issues" "wiki" etc.
I'd really like to see Releases on the top nav bar, and possibly even Readme should be the first item, Code second.
I think partly it's just the inconsistency that bothers me, but when I'm being a consumer of a project it's one of the main things I look at -- certainly more than many of the other top-level items.
* "Actions" are basically only useful to me as an active project contributor.
* "Security" is a pretty niche tab -- I think personally I've clicked on it only a handful of times, ever
* "Insights" I had forgotten about to be honest (and obviously don't use it), but even as I look at it now, I think it's somewhat useful for judging how active a project. For mature projects (that don't need active development) it says almost nothing. I personally do a fuzzy judgement on Releases, popularity, # Issues open/closed, # merged PRs, # and age of open PRs, # contributors.
I use "Releases" as a consumer in mainly three ways:
1) To help judge the quality and maturity of a project, in terms of how easy it will be to deal with as a dependency. Are releases being used (vs published adhoc)? Are there betas? Is there a changelog or curated release notes? Is semantic versioning being used? How frequent are releases?
2) When updating dependencies, and looking for breaking changes or things I need to update in usage.
3) For downloading, when it's the only way -- though this is typically linked from the main README, and I'd generally only care about the latest.
If I know what repo I want and am going directly to it, sure. If I'm looking at lots of repos that match a search (either on GH or somewhere else), say... looking for a library that does a thing and there are many choices, the first thing I'm going to look at probably isn't the readme. More important in those cases for filtering out the chaff are date of last commit and the issues board, looking for signs of life rather than signs of abandonment.
The design before was targeting developers with a "for work" feel. From a vcs perspective and ci/cd perspective it showed the important stuff. The new file browser is especially bad - being Tritanopia color blind the lack of lines and the folders physically hurt my eyes.
But To be honest we all know what this re-design is for. Microsoft pushing Azure Pipelines ( github actions ). The previous github interface was not cute / nice enough for actions. So they re-designed the entire site to be able to push us towards Azure usage. ( that is the entire reason Microsoft Acquired github - slowly luring developers from opensource to the safe walled garded of microsoft. With a slow shift of Azure cloud offerings leaking in to our minds. ). And slowly taking over most organisations tool-chains.
What is an action? And is there really much risk of us using Azure? My code, like most I suspect, runs on linux/unixy things and probably doesn't even build on Windows.
The risk is determined by us the developers. Actions means "Github Actions - re-branded Microsoft ci/cd tools).
Microsoft uses partners to sell their offerings. Many of these have used cross-selling with the arguments of all eggs in the same basket and buying from one vendor "more secure and safe" for decades. Tools like Github and Some of the best and most creative developers not using Visual Studio threatened this method of selling. (the IDE runs and deploys "solutions" to Azure directly - very effective walled garden ).
The free thinking and creative developers had started to break organisations free from the microsoft "safe basket" and the push towards AWS and GCP was hurtful to the bottom line. To counter this a strategy was formulated.
Microsoft rebranded as the good guys. With an image of participating and actively supporting opensource. First they tried with pushing .NETcore. Then they gave us VS Code. Then they aquired Github. And now the cross-selling is back in the game.
The arguments of "one vendor" and "one basket" is thrown in your face again - when dealing with procurement people and internal organisation politics.
"We argue Microsoft as the better option here - we in procurement have a good relationship with Partner X who have helped us with Office365 for years". "They told us you already have The Github from Microsoft. And our Code already lives in Azure. You in IT really need to motivate why a different vendor is required for all this cloud stuff".
And the herd of sheeps are slowly returning to the garden.
Ugh. Yet another design by someone who keeps their browser window maximized (or has the luxury of an enormous display) and expects everyone else to do the same. A few things that leap out at me:
- Large margins everywhere
- Sidebar gobbling up 20-30% of my browser window's horizontal space, no matter how far down I scroll.
- Hamburger menu hiding the dashboard and other frequently used links.
- Latest commit timestamp hidden by mostly useless stuff like tag and branch count.
This layout wastes a ton of space. Information density feels too low, which might be appropriate for a product landing page, but is counterproductive in a development tool. It also makes things needlessly difficult for people who multitask with side-by-side windows or have small screens.
On the positive side, at least this layout is less annoying than Gitlab's "bury everything within javascript menus" approach?
I have the same complaints, I do agree that the new redesign looks great in my external monitor, except I do my browsing on my 14" display and the repo information looks kind of squished into the left.
I don't like the circular avatars - I don't need the place I store my code to feel like a social network.
But the worst change for me is that the 'Languages' section is now below the fold. Now I have to scroll to find out if I should ignore the latest compiler, package manager or system tool because it was written in JavaScript.
Edit: Gah! I only noticed this by directly comparing old and new, but the filenames in the main list are no longer blue, so now on each row, the filename, commit message and timestamp are in three subtly different shades of gray. That, combined with the lack of gridlines just makes the whole thing look like word soup.
> the filenames in the main list are no longer blue, so now on each row, the filename, commit message and timestamp are in three subtly different shades of gray
Shoot, now I notice it too. I like the redesign but that is just.. bad.
Language color bar is one of the most iconic and useful design of GitHub IMO (not sure if GitHub invented it though, since GitLab has it too). It's a shame it gets moved.
I completely agree with you that the stats and language bar were iconic and quintessential of GitHub. It is a massive shame that it's effectively been removed.
The worst redesign yet. It looks even worse than an early version of Gogs I tried. Of course, if you're paying designers they ultimately have to design something even if it's crap. Ideal github design was maybe in 2012.
Unrelated to the redesign, but the documentation for things like Actions just scream "microsoft." It was really hard for me to find the important information; had to sift through pages of abstraction gunk where things aren't explained clearly or with code. Felt like IBM product pages. Very non-github. This clueless internet-explorer-type design trend will almost certainly continue IMO. They simply can't help theirselves.
Unfortunately I also don't like gitlab or bitbucket. Github circa 2012 was the gold standard for the design solution, while everything else was cluttered or pad-y or overreliant on side navigation. Now everything sucks.
The new web design layout on GitHub is awful and has less accessibility.
For example, the repository languages used to be at the top center of the page, while now I need to scroll past the bottom of the screen and find the information off centered in an awkward place.
The stars and other top bar links are off centered in an awkward way for the mouse and the eyes. Also, the profile tabs are less accessible because followers are now on the other side of the screen instead of in the convenient tab location.
Please contact GitHub with your feedback if you also think it's less accessible design.
Oh man, they've made it way harder to quickly evaluate the state of a repo, which has always (for me) been about 90% of the appeal of Github. Moving releases out of the tab list hurts, too.
Does it also feel "heavier"/slower to anyone else? Like there's more JS running or something? That'd already gotten a little worse but I hope it's not trending even farther into feeling "webappy". Ew.
I wouldn't consider any of your criticisms as being "less accessible".
To take your example of the languages, the new design is more accessible. It has a clearly labeled heading, and I can see the names of the languages are being used without clicking on the bar. The old design has no hints that the striped bar (or in the case of `linux`, grey) is supposed to be informative. We're all just used to clicking that bar if we're curious.
It's clear they've optimized the layout around productivity, and making it more approachable to new visitors. Everyone has their preferences, and new designs are always tough to get right for everyone. "Less accessible" is the wrong way to phrase your criticisms, though.
They could have left the languages in the same place where it was before. Now it requires extra input and mental effort to find the languages section. This is definitely a step backwards.
Not complaining about the design of the new languages section, but the layout is just completely terrible and useless.
I would regularly wow people by showing them the language feature existed. It was obfuscated in the old layout and now it's readily available without any additional clicks. Yes, my eyes have to scan to the side now, but to call it "completely terrible and useless" is ridiculous. More users will discover this feature now that it's been moved and made visible.
I have to disagree with you there. Previously, I had to click on the tiny strip before I could see the languages. Now it is available right away.
For a new visitor, this is infinitely better because it is clearly labeled. For returning users, the only hurdle is getting used to the new location (which is made easy by the clear heading).
You could argue that project languages are more important than the contributors and should be placed above that content. Regardless, it is clearly a step forward.
I rarely found the list of languages useful, and never really appreciated the description and the "stats" bumping down the list of files and readme, which are arguably much more important than the former. I think moving the secondary information to the side is a bit better use of space and visual hierarchy.
I don't mind the aesthetic design changes but the layout drives me crazy. I count 4 separate alignments in the new repo page on my 15" macbook's full width browser window!
I found and modified a Firefox user style to fix the alignment for wide windows.
I've been using GitHub since 2008. My default browser has JavaScript disabled for various reasons. It was not long after Microsoft acquired GitHub that the UI changed for the worse, but it was minor and still very functional. Now, it's terrible: the dates and commit information is missing, for example. I expect soon it will reach GitLab "quality": unable to view source code without JavaScript enabled. I'm still on the fence on whether to act on it now, for my own projects, or wait for the fatal blow. Since much of the programming world is on GitHub, this looks pretty bad for me.
> I expect soon it will reach GitLab "quality": unable to view source code without JavaScript enabled.
I also hate GitLab for this, but I learned today that they are actually working on fixing this, by shifting some components to server side rendering. Awkward for me if GitLab suddenly will become the better choice.
The way it looks now, a self-hosted gogs with a nojs patch may be the way forward. The application-specific part (gogs.js) is <2kloc and it's already rendering stuff on the server. I'm giving it a few weeks before I've had enough...
They are following the trends of flat design and rounded corners, which I don’t really mind.
I’m more bothered by the fact that nothing is aligned: the GitHub logo, the breadcrumb, the horizontal menu and the issue title are all on different verticals. Looks messy.
There is a consistent principle behind those choices: rectangles with slightly rounded corners are clickable, while rectangles with semicircular sides (“pills”) are not clickable. It's confusing because I've never seen another site that distinguishes clickable elements in that way, but I can imagine we'll grow to find it intuitive with enough usage.
I felt the same, and even made the same image with vertical lines in my feedback to GitHub while the change was still in the preview stage.
I installed a custom css user style extension just to fix it. Here's a link to my comment with example before and after along with the CSS needed for chrome or firefox:
https://news.ycombinator.com/item?id=23624292
I felt the same, I installed a custom css user style extension just to fix it. Here's a link to my comment with example before and after along with the CSS needed for chrome or firefox:
It's not the layout I dislike but the styling which makes it harder to see what is a button and what isn't, e.g. only 2 of these are clickable https://imgur.com/a/wR9xsvT
I really like it, it's much more cleaner and despite all the comments in here, I find it to be a very smooth transition. I wondered around for a few minutes and pretty much mapped the whole changes.
Looks like nothing I use regularly moved too far away. I like the new top bar (I'm sure this will make it more mobile-friendly). One change I would make is to give the README section a header so it is easier to see where to stop scrolling if you are trying to get to it.
Overall a positive change since the pages are loading faster for me.
Ugh, they've gotten rid of the commit message, because they merged "commits" "branches" "tags" into the header bar. If you want to see what the latest commit was you need an additional click.
Turns out that glancing at the header was useful to tell what was going on!
On the plus side, GitLab's repo view (which I disliked because it felt cluttered and always hard to find what I wanted) is now easier to use and read than GitHub's, so that makes changing easier.
Also, I'm noticing a lot more "preload" pages ... e.g. the page loads with blank placeholder fields for the commit and text information that's then replaced live after loading the page. Maybe it did this before and is just slower now?
My cynical guess is that they used “page load time” as a metric to prove their new system was “faster”.
And maybe only tested internally on a faster system, or with hot-cache repository loads? It doesn’t seem to do it on reloads, though going away for a bit and coming back seems to cause it again (and, visibly, different parts of the page load at different times).
Anyway, It definitely reeks of “enterprise” so I guess Microsoft finally got enough people into github to steer the ship towards the iceberg.
I don't really use the releases section (don't recall it existing, to be honest), but right now it's among the first things I saw when going to a repo. It's in the new sidebar.
The old Github was honestly a terrible UI. Not responsive at all, making it awful on big and small screens. The information density feels the same to me; it was low before and it’s low now, but at least diffs fill my screen (though improved responsiveness is something they added within the last year tbf). Unlike Jira, shit loads without a horrible amount of pop-in, and I don’t really realize I’m using a SPA. They didn’t rearrange the core UI much, and I don’t feel like I’m having to relearn anything. So overall, some ambiguous buttons are my only complaint. Feels like a big improvement that was long overdue.
Contrary to everyone else I really like the new design.
The metadata is placed to the right as it should have always been. The languages are in the sidebar and are visible without me remembering that typescript is somewhat dark blue.
Also the new look is more modern and unlike most people here I am not afraid of change.
> and unlike most people here I am not afraid of change
Hear, hear!
I like the new design too. It overwhelmed me at first (somehow it felt really 'big' to me), and I'm still getting used to it on a visual level, but I appreciate all the new bits of information that I can much more easily access now (mostly in the repo sidebar).
I also appreciate that the new design doesn't actually change that much. Overall, it still feels like... GitHub.
> ...unlike most people here I am not afraid of change
Not every preference is a fear, except I guess the fear that a lot of people will now waste a lot more time learning things that used to be obvious at a glance.
The tables are somehow less dense and less readable at the same time; the added line spacing should have helped with this, but overall it's worse. The controls are needlessly stretched across the entire width of the screen, which these days is most likely wide, so reading and moving your mouse between controls is inherently more laborious (it's also just ugly).
Honestly, it's a positive improvement. Better information layout, and the code is still front and center. None of the core functions really changed place, just changed padding a little.
For the license, it's right there near the stop of the sidebar. For me it's actually easier to notice now.
As for language, it's true, it's below the fold in the sidebar. Maybe it'd be better above the contributors. But for me the most important place for me to see language is when searching/browsing through lists of repos - and that hasn't changed.
Really? I found that I only really look at the code when I look at projects I'm involved in. Usually though I use GitHub for discovery and then I care much more about the languages, commits, releases and Readme.
I pay them money on several accounts, maybe it's not enough and IBM asked them to do this? I'm not sure how well MS and IBM get along, IBM saw them as public enemy #1 when I left, but where paying for GitHub?
Yeah it's clear that they're setting things up to be used more frequently on touch-based devices. Combine that with the hosted IDE, Visual Studio Code, Azure Devops, etc and it's more or less strategically obvious that the goal is to enable a shift in that direction.
Ditto, and doubly so for the README. If I'm scrolled down further than the end of the sidebar, the README, suddenly 40% of my screen is empty, and not even split evenly on each side.
Oh is that what it is? I was trying to figure out why it looked so bad when not zoomed uncomfortably far "in", when I didn't recall that ever being a problem before. I think that's it.
Ugh now I can't un-see how much farther it is to mouse from the repo "body" to menu items (including those associated with the repo, which are now, confusingly, disconnected from it visually) now. Thanks for that.
> Hrm. I just got switched to Github's new look and feel... and tbh, I _don't_ like it. I liked the 3D depth of the prior buttons. The new ones are too flat, the text is thinner, and they're too rounded. I appreciate that people worked on this, but... why was this change needed?
(See tweet for a screenshot comparison of the "New Issue" and "Edit" buttons before and after)
I thought you all were exaggerating. So sorry not.
The commit list looked like it was doing some sort of eventual consistent update, then I realized that hovering over different commits expands that one shifting rows up/down as you hover on different items.
GitHub: under new management. My theory about management is like my theory for bad music at venues. The management greenlights which acts will play, unfortunately most owners don't have a clue, they themselves are not the target audience. There are also legendary venues where obviously they were 'in the know'.
I took it to mean that most music venues are managed by people who don't know or care much about the music they book; however the best ones are run by competent people who are also passionate about the music.
It seems like a pretty good analogy to me. A lot of UI redesigns (including this one) seem like they were approved by people who liked the look of some static mock-ups, but weren't regular users of the site. Lots of layouts look great in a demo but are awful to use.
Even the changelog summary is similarly directionless:
> Today we’ve launched a refresh to the design of GitHub UI, and layout changes to your repository homepage. We hope these changes improve your experience visiting and maintaining repositories, and using GitHub in general. Along with visual design changes, you’ll see the the following updates to your repository homepage:
- Responsive layout and improved mobile web experience
- More content surfaced via the repository sidebar
- Ability to show or hide Releases, Packages, and Environments in your repository sidebar
> These changes lay the foundation for future incremental improvements that will better surface your projects, the people who make them extraordinary, accessibility, and yes, dark mode.
The whole thing reads like it was an update to a landing page, which it is for some projects. But it's also a core point of collaboration and workflow for many, not to be rearranged without precise and deliberate intention for each and every change. A "refresh to the design" rebrand to signal new ownership is not welcome.
Edit: it's even really bad as a landing page. I just realized that the README is now often 'below the fold' because of so much linespacing whitespace above it.
The 'refresh' was clearly meant to be for its own sake and any improvements secondary or incidental.
I was only given at most a couple of weeks to provide feedback which like everyone else here was negative.
But to have it launch now means that they never had any intention of listening to real feedback. They just wanted to see if there were any showstopper bugs.
I gave feedback too and never heard anything. The rounded corners look cartoonish, the header is terrible, moving releases and using a new column at the right is terrible. Seriously w-t-h are they thinking? there was literally nothing wrong with their existing UI.
I'd make the languages bar expanded by default, and for repositories where I rarely contribute hide file list elsewhere (like on mobile), bringing README to the top.
Not necessarily. I've seen the concept of "vocal minority vs silent majority" used as justification to push through a change. So even if you get only bad feedback, it still goes through because most people said nothing, which means most people like it.
Or most people hated it but didn't love the product enough to care to comment. Perhaps the design of the feedback form matters. I wasn't part of the beta so I don't know how they asked.
They didn't ask, you have to go into the feature view menu (under profile) and then click a link there to go to another page and then have a form to fill out.
They know UX for sure!
Maybe we should send them a copy of Don't Make Me Think
Same here - but it also feels like I got the feature preview notification maybe a week before the feature actually launched, two weeks max. Didn't feel like enough time for me to properly test the new interface, or for them to properly evaluate feedback.
I gave some feedback on this as well but unfortunately I only saw the preview like, two days ago. Have I just missed it or did they not roll this preview out earlier?
I got it on 19th June (I remember because it was the day GitHub went down). I left feedback, but it feels like it would've been a foregone conclusion at that point.
I don't much care for it. It seems to make much less efficient use of screen real-estate. Information that used to be clustered tightly together is now spread all over.
It seems to me like someone who doesn't actually use git professionally just arbitrarily move things around for no discernible reason. The UI elements that have moved don't seem to have any particular rhyme or reason. For example, apparently the "security" tab is worth being in the tab bar, but the releases aren't?
Frankly, I think it's inappropriate for a professional tool to change it's UI arbitrarily, or even for a marginal benefit, since all of the great many existing users now have to learn the new UI. These things should only be modified if there is a clear and significant benefit that justifies the trouble.
This makes me glad that I'm a Sourcehut user ( https://sr.ht/ ), since it's UI is much more sensible, and faster to boot.
On a 3840x2160 res it looks horrible, extremely stretched and honestly it looks like someone's first web design, and if you zoom in it looks unbalanced.
There's no reason for the major layout change.
Sadly, this seems like yet another case of designers/project-managers having nothing to do and wanting to feel useful every once in a while so they go about redoing the design. Paypal, slack, spotify, and many others do it all the time it, so why not github.
Quick hack for Ublock Origin users to get everything lined up again (add this to your filters): github.com#$#body{ max-width: 1280px !important; margin-right: auto !important; margin-left: auto !important; }
That's perfect, thanks! I usually resort to Firefox's userContent.css file, but the feature is now disabled by default, so I'm glad to hear uBO can do it too.
Did GitHub only test their new layout on 4/3 screens? It looks so odd when the project header is fluid but the project itself is still centered and 1280px wide. Especially if you log out of GitHub, in which case the GitHub banner is no longer fluid and makes the project header look really out of place[1].
A 13" MacBook would have an effective horizontal resolution equivalent to 1280 pixels. It's likely that they designed this only for 200%-scaled laptops.
What a poor design, yikes. Did they seriously just use an off the shelf 'responsive' template and not think twice? We are programmers, this is code - give me information density!
It's indeed much better on mobile, since the old design not only hid most of the README, but also lacked many useful indicators from the desktop version (languages, releases, etc.)
The thing is, they just released an excellent app, which was seemingly meant to solve the problem of browsing GitHub on mobile. It's a bit surprising that this design, by many aspects, seems targeted towards mobile users and is already displaying more useful info than the app.
i always find it hard to read tiny text so my zoom level is always between 120% and 150%. they fixed all my issues with this update and that made me happy.
Alright, that's a big of an exaggeration but I don't feel like this change is nearly good enough to warrant significant changes to a professional tool I use. Like if you want to completely change my user-experience you better at least have a reason, not just do it for-the-lulz. After trying it out for a while under the feature preview I really don't get why they did this.
It's never been a good time to try something else. That something new is GitLab.
GitHub however, capsized one of its servers yesterday resulting in downtime for some including me and today I wake up to this horrific eyesore that Github has blasted onto my screen, which I can't revert or disable.
It now looks like a shameless rushed copy of the GitLab look. I'd rather use GitLab for real instead.
What do people feel about the code at the top (both old and new)
The thing I think I want at the top is the readme. If I'm looking for repos I need to know what it is before I look at the code. If it's a repo I'm working on I'm more likely to look at the code locally then the code on github. When I do look at the code on github it doesn't need to be on the front page for me. https://github.com/username/reponame/code or the links to various branches would suffice for me. Even if I am looking for the code the 95% of the time the code is not above the fold, instead there are several lines of folders and config I don't care about and so I still have to scroll down or search. In other words, the code at the top doesn't even help for code.
To put it another way, the code at the top is actively hostile to what I need to get done.
By "want the source" you mean you want to look at the source via the gitlab website ?
I would interpret "want the source" as "I want to download the source" in which case showing the files is useless. All you need is a "download source" button
The conversation was about viewing the source online vs the README so clearly I meant I want to glance through the source online. There's a few reasons I might be doing this:
- before deciding if I want to clone the repository.
- Or sometimes I might just want to check the hooks of a particular API (eg the outputs of a Terraform module) where there isn't really a need to manually clone the repository just to validate some assumptions.
- Sometimes I might want to quickly verify the code that's on origin master is up-to-date (everyone has committed PRs and merged back into master).
- Sometimes I might just want to validate what code kicked off the CI/CD pipeline.
- Sometimes I might be demoing some changes in the sprint review and rather than spin up another IDE / switch branches / etc I might just open a new tab and walk the team through what has been committed on Github
Also nobody was talking about Gitlab specifically. BitBucket and GitHub were mentioned though.
How would you know you even want to look at the code at all if you haven't read the description of the code which is currently below all the code at the bottom of the page?
I need to know what the project is and what it's trying to do before I have any interest in looking at the code.
I actually like it but I miss the small bar at the top containing the links to the releases, commits, language information etc. in a single place. However, I have a quiet big display with great color settings and didn't try it yet on my smaller laptop displays.
I guess if your display doesn't show the light grays and shadows as well it may suck.
I feel GitHub is making a lot of changes in a short amount of time and as someone mentioned earlier, it really leads to additional friction in our workflow. When we get used to one layout and then they change it, there is time and effort required to get used to the new layout. It's fine if there is some clear benefit, but I don't see any such benefit in this case...
This feels like a huge step back. One of the first very obvious bits has been pointed out numerous times in this thread already: The main panel is shrunk down while various navigation is off in no-man's land.
Tools which change like this never stand the test of time. A far better move would have been to standardize GH APIs and provide native clients, guaranteeing long-term utility on many platforms. Git passed the test of time, but github likely will not.
Edit: today I learned a lot of young people sound like old people. Interesting perspective.
The new layout of the repo screen is decent, but the new, overly-smooth UI components are too much of a departure from the previous, well-done UI components.
The way the top tab/nav bar stretches across the screen, while the content is centered feels broken to me.
main repository view on widescreen puts all the "Code, Issues, Pull Requests etc..." buttons way over to the left. Why not just centre it like the repository files view below it? Seems completely bizarre and adds extra mouse movement between files and the buttons above.
Overall this design change doesn't matter to me. The only thing that really stands out and that annoys the hell out of me is the circular profile images. It looks completely out of place compared to all the other elements on screen, even their generated profile images don't fit in it correctly. It seems that this decision was made not from "add value" point of view but someone just really liked Instagram or the look of some other social network and shoehorned it in there.
I haven't had too much time to play around with it yet today, but Github is core to our development workflow and productivity workflow. Everything for our small team is tracked in GH issues and tagged with labels, and of course all our code goes through GH PRs. IMHO the features I use most (issues, pull requests, code browsing) didn't take any discovery to continue using normally and the interface was much faster, so I am a fan.
The only way they could do such a thing and not drive people away would be to come up with more useful features, but their redesign seems to have less basic functionality than the old UI did.
Microsoft will understand that github users don't care about their "branding" and if they don't, they'll simply drive those billions of dollars into an early grave like Yahoo does with everything that Yahoo buys.
>the buttons in the header are separated to the extreme ends of the screen
>...but the elements in the global site header aren't (for some reason)
>the selected tab has a thin underline which is harder to recognize than a colored background, and isn't as clear (does it mean I'm currently hovering over it, does it just mean that section is important, is it the same as a notification badge, etc)
>the main column is off-center
>there's no separation or contrast between the list elements, making it harder to align things by eye
>the readme section doesn't have a header, making it look like the text "README" is part of the document itself
>there's an entire second column in the layout, placing both on an equal level of importance
>...but it only has a single paragraph in it, which leaves you with an empty column taking up space 95% of the time
>if a project doesn't have something, the sidebar will simply omit that section instead of showing the same element with the text "0 releases", "0 branches", etc.
>...which in turn trains you to ignore the contents of that column and not expect to find things there
>this also applies to the "about" text, the purpose of which is literally to be the first thing you see when loading the page - now in the sidebar, sandwiched between three lines of text in the same font, color, weight and length
>the labels at the bottom of the page are spaced out evenly, which actually makes them feel HARDER to click (the sizes of the hitboxes are the same, they're just much further apart) in addition to looking ridiculous
Guys, stop complaining. You're just afraid of change.
Well I can tell it's a Microsoft project now. Not in a good way. People almost never like re-designs so maybe it'll feel natural later, it's not terrible. Just sterile and corporate feeling.
Yeah. I think that the new layout is fine, but I really don't like that it doesn't look like GitHub anymore. It looks like every other modern UI out there.
Worst UI update to GitHub I've ever seen. Reminds me of GitLab. Who thought this would be a good idea? Shame, they could have used the resources for updates that would actually make GitHub better.
I don't see what's wrong with it. One thing I love about it is that I can now finally read readmes even if the window is only half or even a third of the width of my screen. Other then that it just looks a bit more modern.
One thing I just slightly dislike is that the width of the body is limited, but not the width of the header. Looks inconsistent.
They used to be full width no matter how wide your window was (I put to 1/2 for browser). Now they only occupy 70% of that space. So I just lost 30% of my readme width to empty space. This is just terrible UX
GitHub never had full width pages before of the Repo interface. They used a giant gutter on both sides on widescreens in classic Web 1.0 blog template fashion. That ~30% empty space has always been there beside the README, it's just now consolidated to a single side and used to bring a few more bits of information "above the fold".
Since the repo screen is now basically full width, why not add a simple commit stream on the left? (So make it three columns instead of two). The most important thing I look for when checking out a repo, is how much commit activity there is and what sort of things are being worked on. It gives you a good sense of the health of the project.
So in the middle you have the files, and the action buttons above that, on the right you have info on langs, the contributors, the "About" blurb, but on the left you could put a (live updating?) commit stream with just a small contributor pic and name, hash, time stamp (x days ago), and the first bit of the commit message.
EDIT: Instead of just a commit stream, why not add a "repo feed" on the left? Includes new issues, PRs, commits, etc. Live updates (animates new ones bumping into the top).
I'm completely neutral. They've changed their UI many times over the years and this is no different. Products usually change UI and that's just a fact of life.
Most of the time it isn't bad UI but a vocal minority that just hates any change.
It's not like these companies release these changes without doing significant user testing and AB testing. If you design based on the opinions of HN/Twitter, every site would look like Craigslist (or HN's favorite abomination of a design, the Berkshire Hathaway site).
I'm not sure yet, 30 minutes isn't long enough with it to form an opinion. My initial reaction was, What? Why has this changed? I didn't see anything wrong with the old one.
I do like that sponsors appears more prominently; for a very long time financial incentives have been an unsolved problem in open source.
Imagine waking up one day and suddenly your apartment is completely different than when you went to sleep. You stumble around, bewildered. You go into the bathroom... and it's the kitchen. You go back and turn left around a corner... and it's not the living room, it's the garage. The entryway to the living room was through the kitchen.
According to the new designers of the apartment you rent, this configuration is much more efficient. Meanwhile, for the next two weeks, every time you want to take a pee, you end up wandering into the wrong rooms looking for a toilet.
Product Owners: please don't treat your users like an afterthought, or refuse to help them adapt to the changes you didn't even ask them to accept. It's careless, and makes users immediately dislike your product.
I like that GitHub is one of the few websites that kept roughly the same design for years. Design is something that gets familiar, and I believe it helps your brain when it is not changing all the time. I would like to see an explanation from GitHub's side as to why this change was needed.
A related question: Why is it so hard to find a most up-to-date fork?
When I come upon a useful lib, there would often be hundreds of forks. 99% of those forks don't make any commit on top of upstream repo. Why even bother forking if you're not actually changing the code? Can we agree those are useless and just hide them in GitHub interface?
You can list all the forks on GitHub, there's even a nice hierarchy, but no other information. So you open hundred tabs and scan all the forks to see if they are ahead or behind the original. There must be a better way! Few years back there was a graph that took forever to load, but it gave good idea of commits that each fork applied on top of original. Is it still available?
Yeah, it's bullshit. I think once a company gets "big" and corporate enough, focus somehow dissipates away from actual usability into...something else. See also: all recent changes to Slack.
Maybe this is just because the best people are drawn to work on new products?
Another insane example of this is scrolling in the iOS AppStore app. If your finger happens to start a scroll on a button, the scroll is just completely ignored.
Apple used to write entire carefully-considered tech reports about how to handle this case (until the finger starts to move or some time has passed w/o moving, you're in a limbo state where a button tap or scroll can't be distinguished), but now they don't even try to get it right.
I mostly don't mind (like 99% of redesign these days, it is pointless), but the new one makes many things harder to read:
- I don't know which menu or tab is selected (the tiny border is not obvious enough)
- The buttons don't have a state anymore, so figuring out if I am following this repository or not is difficult
- The file browser does not have a clear separation (border) for each file, nor does it have alternating background colors. That makes the navigation harder.
- I am disappointed to see that the redesign did not get rid of the useless in-page loader when I click on a link. This is annoying and breaks my normal navigation.
I am no UI expert so I will not try to evaluate the old vs new UI. However, I want to say that I really like the way Github has looked and functioned. It feel lightweight and it feels like someone just built it up from basic html. For example, you can right click the "go to file" button and open it in a new tab and it works like any standard link. Compare that to any button on facebook or youtube or gmail which are probably not even real html buttons, you can't expect them to properly open in a new tab.
Personally, I love that it fits perfectly in exactly half of a 15-inch Macbook Pro screen. That's always how I have GitHub open and it bugged me that it didn't fit right before.
Hoowever, the increased use of horizontal space makes it harder to read (imagine HN without the blank sides) and I believe the information density has been lost a notch way too much.
All in all I think I prefer the previous design because to me information readability comes first.
It actually becomes pretty decent if you zoom out to 80% in Firefox although the text becomes a tad too small. I believe making an extension to increase information density shouldn't be too hard.
Nothing has been improved, only changed for the sake of change. A redesign without a user requirement or business concern indicates mismanagement. If designers or management wanted a new look they should have coupled it with functional interface improvements. Changing the style alone has a lot more potential downside than upside.
And of course in the quest to re-skin everything for no reason, important things like last commit message and status were removed.
Indeed, that is shitty cloggy.
Yes a MS or Google move where you break something that works well because of product managers that want "new things" to sell.
1) it lists "contributors" in the corner and listed an old employee which made me worry that they were still able to access the repository. they're not. i don't need to see their profile on my repo, it's not helpful
2) because of that I noticed that i'd been paying for two additional seats for god knows how long and downgraded. I'm kind of disappointed i've been overbilled for no reason
They could use some alignment. It's one of the basic rules in design, and it really seems a bit off when the files are centered but the hmenu with Issues, PRs... is left-aligned. Maybe they had some cramming issues when there are many extra buttons in that row, since some only show up in certain cases, like the Settings button.
Other things aren't so bad but I don't think they make up for breaking the general alignment in such an obvious way.
It feels like change for the sake of change to me. There doesn't appear to be any actual improvement in terms of UI or functionality as far as I can tell.
It's fugly. I thought a plugin broke rendering on GH. This seems like a change for change's sake -- I don't see what this was supposed to accomplish.
Put back the "releases" link where it belongs for a start. And why is the code-issues-pullrequest etc left-aligned and the content it governs centered? How did this get out the door?
I've been previewing this for a while. My biggest gripe is the treatment on all of the buttons. They look like they are depressed when they aren't and don't stand out as remarkably as a call-to-action the way the old buttons did. The easing on the hover animations is way too slow, as well. It just feels half-assed.
A few months ago I think there were some fan-made "GitHub redesigns" floating around that sorta looked like this. It kinda reminds me of those crazy futuristic video game console "leak" videos (à la "This will be PlayStation in 2020!!") followed by the reveal of the actual new PlayStation design.
Right, like this is such an obviously bad design pattern and yet they still do it. I just don't understand where design is as a science or art anymore...
It is redesign for sake of redesign unfortunately. My guess is GitHub/MS has a bunch of designers paid full-time and they need to justify their salaries.
I think it's great. It's about time they started using more of the available screen space. If I want a tiny view I'll shrink the window.
Since this seems to be such a contentious issue, I wonder why they didn't keep the original style around as an option? Aren't stylesheets supposed to make that easy?
Why would I want to be able to see a bunch of meaningless icons for contributors? Why is this being prioritized in one of the highest visual-traffic sections of the layout? Why would I want to see what percentage of the project is in different languages as a high priority piece of information?
Like, 100% agreement with everyone complaining about how the sidebar de-centers the README, agreed, that's awful, but what rubs salt into the wound is the sidebar is full of useless garbage! Both as a contributor of code and as a consumer it's hard to imagine things I'd care about less. Have it in a cute little "info" tab that no one will ever click like all useless information, and keep the landing page of a project for essential information.
One very important positive thing is that the whole readme is now displayed on mobile version and that is the one which is indexed by Google.
Previously they only shown few top lines and thus all README was not visible in the search engine. Something that awesomeopensource took huge advantage of.
I wish they can enable google analytics on Github pages.
It’s a good redesign. Not great but that’s ok. What we need to talk about is the quality of the criticism. It on par with the “why would anyone use Dropbox when rsync exists”
People hate websites that look like they were designed by a programmer. Programmers hate websites that look like they were designed by a programmer
Fullscreen on my large monitor it looks ridiculous. On my phone it seems ok, except firefox crashed at one point.
Developer tools should really be desktop first, instead of mobile first. I always wonder why we all use bootstrap as our goto so the site works on mobile, but then twitter barely works on a mobile browser.
Some positive feedback that may be overlooked with all the UI changes:
Love that releases are shown prominently on the repo page! It's always been a 'trick' of mine to check for releases for a repo by appending `/releases/` to the URL. Now I don't have to, and can just peek at a glance.
It's broken for me, thanks to the "responsive" design. When the browser window occupies half my screen (1920x1080px), the top-right menus (bell, plus, profile) get replaced with only a bell icon. How am I supposed to reach the settings page now?
I often go to a repo and look at the recent commit history. Maybe it was just muscle memory, but I keep struggling finding where to click for this, especially on mobile. Doing this now takes me considerably more time with the new design. (been on this for a week or so)
The worst part for me is the rounded avatars (the other rounded stuff is okay). So many pictures on github weren't built for rounding. My own avatar is cut off as well. I hope they revert it, but if it sticks around for a while I guess I'll have to update my avatar.
I guess the upshot of GitHub burning their design advantage is that I no longer have to justify that when using GitLab. As a relatively long-time GitLab user, my feedback every time they change the design (often for the worse, in the same way as GitHub has now done) has been “make it more like GitHub”. Now what do I point at? SourceHut?
I guess it is SourceHut actually; I think it could use a bit more texture/skeumorph on things like tabs and buttons, but it is so clean, especially since it uses my default sans serif font (which is condensed). There's just so much to do right, see: https://qui.suis.je/drop/sourcehut.png
A friend of mine dislikes the redesign due to (a) the sidebar taking up too much space and (b) the lack of gridlines in the file listing. Here's some CSS that addresses those issues in case anyone else wants to blast it in via browser extension:
I do like that the page does a better job of filling the window; nothing irks me more than wasted space.
I also like that it's a lot friendlier to narrow windows (no horizontal overflow/scrolling); makes it more convenient to put it side-by-side with something else.
It seems fine to me in that I'm using it and have barely noticed apart from I have to scroll a bit more. It always amazes me somehow everyone thinks of the same ideas at the same time. MacOS Big Sur feels very reminiscent of some of these changes...
Never liked how Microsoft designed things because it feels unfinished and contrast of colors is bad. Certain content is pushed to the edges of the screen for no good reason and some of the fonts are a light in color making it hard to read. The commits link is not obvious anymore that it's clickable.
The redesign is not that bad but there's still a lot to improve on. Before it was easier to scan the page from top to bottom but now the page feels a lot more busier because there's more dropdowns and sidebars. I feel like my eyes are jumping all over the place trying to locate things now. Wish they had chosen functionality over design.
Personally I would love to see some fixes to the project page where with the new Design you waste ton of space on the screen for things that you could see before just in a small row now they take 20/30% of the right part of the screen just if you don't scroll and if you scroll down you get 50% of the screen or more just white...
It looks kinda (being liberal here) like the old theme, but slightly worse and it has issues:
1.) Everything feels left especially on my 21:9 display. This makes going from opening issues to clicking "Code" a very long mouse movement.
2.) There aren't grid lines on the file view.
3.) It looks unprofessional. Professional tools have this feel to them, and this new theme doesn't have it. It feels like a toy that shouldn't be in the toolbox.
At this point I may just move to GitLab. It seems more feature packed and you can have it mirror a repo to GitHub for the users don't want to make the switch.
My browser window is 1059x751 (inner dimensions; to get yours, open your web inspector and type window.innerWidth). For context, this is a desktop machine, but those dimensions fall into Bootstrap's "tablet" size. The only thing I immediately noticed is that README's on the project root have lots of wasted space to their right. Interestingly, historical versions of Github seem to go back and forth on this (the presence of a sidebar) every major redesign.
> Migrating to gitlab...
Wow, some serious "looks like JIRA" PTSD there. Did Gitlab promise they wouldn't redesign?
Personally I have noticed some changes, but nothing that impacted my productivity in any significant way, and paid no more attention.
I believe sometimes we tend to overreact to certain changes that have minimal impact on our lives, because of our attachments to the tools. For instance, on HN, we seem to get a sea of "That's it I'm moving to Firefox/GitLab/etc.." comments often when their counterparts change something. Sometimes those reactions seem warranted, and in this case, not really.
The commit message not being shown anymore and the CI status badges not showing up kinda suck. Otherwise, as a repo maintainer I don't really see much other benefit.
As a user, I do appreciate releases being just... there on the front page. That's really about it though. Everything else sorta just feels the same.
Also, I don't mind using the right side for more information but... can we just left-justify the whole page instead of centering it? It'd provide way more space for info on the right and wouldn't... just be completely empty on the left.
I'm not a fan of the repo being center contained, but the navigation being full width. Things don't line up like they should and it just looks weird. Otherwise no real complaints about it.
With the new notification layout, I lose a lot of vertical screen real estate on a laptop. Between the site header, the repo header, and the notification bar I probably lose 50% of my screen.
Not sure if it’s part of the new design or just a feature I haven’t seen before, but converting links to a line of code into a code view displaying that code in issues is great.
In aggregate, I neither like it nor hate it. But here's what I hate:
* It's even flatter than the previous layout, which makes it more difficult to use. In particular, it's easy to miss the branch dropdown.
* It no longer shows the last commit message, which is an extremely useful thing to be able to see, as others have noted. If space is an issue, they should shift the junk on the right of that section up beside the 'branches' dropdown.
I tried the new layout when offered as a beta feature and very quickly realized it was a regression in terms of ease of access to the information I want when I navigate to a repo page. I’ve submitted multiple feedback messages and was shocked when this was pushed through. Natfriedman, please consider these points.
I'm surprised I'm not seeing more people talk about source hut (https://sr.ht) on HN. If you're a github/gitlab/git* user it does all the things you want, has a lightweight text focused interface, it's run sustainably, que demande le peuple.
I am not affiliated with Source Hut in anyway other than being a satisfied customer.
I also don't really like new design of main repo page. Repo short description on the right – so inconvenient. BTW this is how it looks on mobile: https://i.imgur.com/SqV23WN.jpg - the most interesting things about repo usually located in first lines of README - now we can't see it.
They need to get rid of the “sign up for GitHub” thing, which is especially egregious on mobile where it’s half of the initial screen. I hate having to scroll just to see things.
I’d imagine 99% of visitors are on GitHub but, like me, are not always logged in and I’m not going to when checking simple things.
Made my own userstyle to alter it all.
I removed a lot of the rounded corners on pretty much everything.
They're still round (2px perhaps), but not as dramatic as they are being served.
Only problem is that I didn't save the damn thing before my browser crashed.
And critically, made avatars square again
Ugh, that's not good. Latest commit message and date will not display under <> Code without Javascript enabled, but if I click around in the repository and go back to <> Code or keep refreshing the page, they suddenly show up, still with Javascript disabled. Can anyone explain this?
However, I do like the visual part of the new layout.
I don't see commit messages inside the "Code" menu item anywhere, with or without javascript or reloading. You have to click a commit hash to see its message. I think this is an improvement.
Everything which is a list becomes harder to read / get an overview due to the new width (files, issues, PRs). Color changes don't exactly help either.
But for the diff view, it's great to see more of the line width.
Miss the last commit message and especially the status of it. Seems like a major loss of information to me.
The releases on the sidebar is handy, but something about the top of the page feels... disconnected. I think I’d like the “about” section at the top rather than in the sidebar. Getting rid of the double nav is a good improvement.
The non-centered readme is a little triggering, but maybe I just need to get used to it
Ugh, just realised how bad it is. The menu bar and repo toolbar are float left/right but the repo content is in a centered max-width div which means that it does not align with the buttons and text in the bars above it at all. Who the hell came up with that design, it's unusable!
Hmmm. The new design seems to be pushing hard towards "dev in the browser" with the new. "Add file", which forks the project, and drops you straight to editing a new file, ready for commit.
Kinda interesting. But beyond a README, I can't imagine making any significant edits this way.
>> They've added a right-sidebar that shows various info about the repo in general, like what the last release is.
How do I get rid of the right-sidebar ? This is terrible and a complete waste of real estate. And hopefully someone will tell me how to get rid of it... Thank you !
My only suggestion in to move the Sidebar to the left when viewing a repository's files/commits, or at least give us the option to do so, which is easily doable by injecting custom CSSs into the page using Stylus btw.
Everything looks great so far, so kudos for everyone involved.
I don't have repo on GitHub, but the mobile version is better for me so far. It uses all the screen space, and now we can finally see the language bar (% of languages used in the repo) on mobile version, which wasn't possible before.
I'm pretty change-averse, so I tend to navigate sites like GitHhub by memorising URL paths of pages I frequently use. For example, I have /commits and /releases memorized. This makes it much easier for me to adjust to weird design changes.
I don't like the clone button is now a big ugly pill button. I will probably get used to it, but damn you github UX designers, fixing what ain't fucking broke. You should use your fucking creative brains for real problems, PLEASE!!!
The only problem I have with the design is the repo header not being centered. I'll fix this with some userstyle CSS but it's a terrible design pattern. Other then that I actually really like how it looks/feels/works.
It does not feel like GotHub anymore. The old layout always had a more robust feel. Now it is too modern. The main thing that bugs me is that the languages of the repository are at the bottom right now instead of the top.
I don't think it's worth "migrating away" but the new design does feel even flatter to me and the removal of row lines is a step back in readability. I feel like my screen needs further calibrating...
Like with every redesign everyone will eventually get used to it and completely forget how the old one looked. When the next redesign happens everyone will rage the same way and say they want the "old" design back.
That's because the switching cost is less than the payment of inconvenience. Plus the inconvenience isn't permanent... it fades as people re-achieve workflow parity with the previous design.
This happens with every redesign so no, your assumption that complaints automatically means it's a bad design is wrong. Just wait and see. It won't be long until everyone (including you) have completely forgot about the old design.
The difference is that it's about a service you use a lot so you automatically get conservative and defensive about the design. This is no different than people joining groups on Facebook "WE DEMAND THE OLD DESIGN BACK" every time they do a redesign.
Not a fan of the new rounded corners on everything. Also, don't like how a repository's navigation is no longer aligned with the content of the repository itself. Just seems off.
Agree re the rounded corners. I think they were rounded before, but only two or three pixels maybe. Now with the greater rounding (which also forced them to increase padding to accommodate the rounding), it looks kind of cartoonish, rather than crisp and polished as before.
The header sucks on the ultra-wide monitors as you have one set of the buttons on the left side and other on the right while the main content is in the middle.
It completely destroys typical page parsing habits.
I think it's fine really. I wouldn't say it's an improvement over the previous version, but it's not worse either. Took a bit getting used to, but I can still find my way around the repo.
I'm used to Jira changing their interface more often than my socks get holes in them. So this is small potato and my well trained UX boobytrap avoiding subconscious navigated it beautifully.
I don’t like it either. White spaces and margin added for the sake of clarity when it makes it less readable. No more strict centering anymore. Avatar being rounded makes them loss information.
I feel like they are setting up a design iteration pathway to making changes that will ultimately make it look more like vscode. Seems like a MSFT influenced-thing. Don't love it.
It's a disaster. I was so happy that i could just turn it off but now they have removed that option. Reddit really has done a great service keeping old.reddit.com, wish gh did too.
I use GitHub very little these days, and have mostly removed it from my daily workflow. But, on the whole, I mostly like the new design. It's more pleasing to look at, and doesn't really interfere with the things I still come to GitHub to do.
I still feel that the notifications redesign was poorly done, however, and that's where I spend most of my time. I ended up completely disabling almost all of my GitHub notifications as a result. The notifications redesign drove me from visiting GitHub a a few times per day to a couple of times per week. But to be honest, my usage was already on the wane by then, it may have just accellerated it.
I am really not enjoying the fact my eyes have to move from center where the repo contents are to the top left to see the navigation... I really liked it when it was all centered.
I really like it. Looks really good. It's possible that they could put more information on one screen, but I'm sure they'll iterate and add some tweaks.
My biggest problem is the Find File feature no longer shows up on mobile... This is a super handy feature for mobile specifically. Hopefully they'll put it back.
It doesn't look good, but it's not that bad either. But I don't think GitHub needed a layout change on desktop screens. They should increase the margins a bit.
I got the option to opt into this "feature" a few (4? 5?) days ago. I've been intending to give feedback, but haven't had time, yet, to take screenshots and marshal my thoughts.
I don't want to over-perform it, but I'm annoyed GH bothered prompting me for feedback on something that they were going to general release in less than a week anyways. I'm not really a cranky person, but I already wasted an hour of my life looking for some good plugins that would help me annotate the page to illustrate my thoughts.
I have a billion things more important than giving GH free feedback on my plate, but I was nonetheless naively looking forward to giving feedback on it because it was the first time I've ever been opted into a UI experiment where the ability to give feedback was so prominent that I felt like anyone actually gave a shit.
So. Now, I'm cranky.
1. The visual alignment of this design is miserable relative to the previous. I'm willing to entertain counterpoints from the actual designers here (and I do appreciate that this design is more responsive). I was going to send a number of nice little graphics illustrating how multiple strong visual lines are destroyed by this layout, but I'm not frittering away any more of my life on it, now.
2. The list of releases is probably the single most important signal on the page. And now, if a project has no releases, it's just an absence. There's no indication. I just have to know, from its absence, that there are no releases.
3. It's covered elsewhere in the thread, but I agree on the languages being moved. Someone notes that the existing location was obscure; fine, just force the existing indicators to expanded-by-default. They were in the right place. The second most important signal is what languages a project is in. In some responsive views this information is now at the bottom of the page. This is absolutely backwards.
Everything else on my commentary list is probably covered elsewhere here. If not, I don't really care.
P.S. In the future, don't jerk people around with feature opt-ins with less than a week of turnaround on feedback.
I must be lazy. I don’t want my eyesight travel from left to right in like 100ms. It should be like notepad, open it up and resize it whatever you want.
This is my biggest gripe with it. The sidebar only extends down for a short length, but causes the entire readme to shrink and results in a lot of empty space. I'm indifferent to all the other changes but the readme shrinking for no good reason is quite annoying.
Yep. The languages used in the repo is the first bit of information I look for. That little visualisation was a very clever feature and a highly efficient use of space.
Others have outlined some specific issues such as commit status not bing visible from repo view, but besides a few things like this which will likely be fixed quickly I think it's a cleaner a more modern looking design. It's easy to hate on any change simply because it requires some effort to get used to, but I think this is one of the good ones.
it seems they also migrated from server rendered pages, which were a beauty, when you were inspected the network tab. to polymer, which itself, is good and lightweight. Github was one of last big companies not doing heavy spa stuff.
new ux sucks, on a wide screen content is no longer properly centered, horrible left float, right float on different elements of ux vs center box previously on core content elements. ie, it`s a bug not a feature.
I like it. Wider content, improved IA, cleaner graphics, and mobile support. I can see people not liking the repo nav being fullscreen with very wide monitors. Maybe an option to pin it to the content width would be useful.
I agree. I was afraid I was gonna hate it, but it left me largely indifferent. More white space, rounder buttons, round avatars, wider and more centrally positioned content area, new icons, slightly different colors. Whatever.
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.