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.
By the way, HN body text is 13.33px, about 10pt.
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.)
Agreed – the right column is a waste of screen space and makes the reading experience generally unpleasant.
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.
Would have been nice that it was deployed as the same time as a new layout that’s completely harsh on the eyes.
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.
Agreed about the right column. Distracting and leaves much less room for what matters, typically a README.
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.
I hope you read this!
It’s great to read this comment – it’s always nice to know that community suggestions aren’t just cast into the void
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!)
Reminds me of when HN added the [-] and everybody complained it was on the wrong side but they couldn’t be to fix it.
I love that it’s on the right. It means when on mobile, I don’t accidentally upvote something that I meant to collapse.
The up / downvote arrows are too close together. Always have to pinch + zoom to upvote.
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.
Thanks for gathering feedback!
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?
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.
For the “Why don’t these line up?” pieces, it looks like the new layout was designed for window width of about 1350 pixels.
When the browser window is that wide (for FF anyway), the whole layout seems to line up well.
When the layout is wider than that (eg full window width), there is unbalanced white space all around.
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 ':'
Please fix them.
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.
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.
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?
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.
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.
I started rereading The Design of Everyday Things by Don Norman last night.
They be building Norman Layouts at GitHub
> 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
The number of broken master branches I’ve seen on Github is astounding. So I find the CI status indicator to be very useful.
> 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.
Wow. I don’t get it. It’s still very similar just a bit worse all the way around.
That was my initial thought too. But I discarded it as conservatism, and giving it a try.
To be fair, likely there’s not much difference. One good thing I noticed is now there is a link to the the latest release.
> 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.
[1] https://shields.io/category/build
> Maybe they are trying to push towards using badges/shields inside the README
If they’re pushing for that, then keeping the README below the file list seems counterproductive.
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.
There’s also the issue of the huge amount of white space within the files table. And the lack of centre alignment of the table.
Also you used to be able to hover over a commit and see the full commit message. That doesn’t seem to work anymore.
Overall, seems like change for the sake of change. Boo.
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
100%. This was the first thing out of my fingers today. I want to fully use github actions. Status is huge and getting to a build is a must.
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.
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 (2560×1440).
> 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 (2560×1440).
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.
The problem is your resolution. I have a 4K monitor and have Git/IDE side by side and the layout is a real problem.
It’s 30cm/1ft between the Issues button and the main table.
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 2560×1600. 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.
Seems like a bug or probably an oversight. Don’t think that was intended
I hope so. I just noticed their beta period ended.
I am not sure if they changed anything from how it was previously in the beta.
I don’t think the new design is bad, it’s just different. It’s fine tbh, but these top bars are pretty bad on a big screen.
Hopefully they’ll change that soon enough.
I think they designed it using regular sized screens, works fine on my 13” laptop.
Honestly – pretty refreshing, designers typically forget to test on low end monitors – not high end ones!
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.
> I don’t understand why people are complaining like it’s an absolute disaster
what website did you think you were on?
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.
I……. have to disagree, though I’m not sure why, but that old one looks much better to me. Like it’s simpler and more clear.
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.
> I don’t understand why people are complaining like it’s an absolute disaster.
Because like many developers I use Github dozens of times a day and it’s a major regression.
It’s the equivalent of giving a Chef a blunt knife and wondering why he’s complaining about it.
> new: https://github.com/torvalds/linux
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.
Exactly same as my feeling.
I am okay with most of the changes, but not left aligned README.
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.
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.
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”.
“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.
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.
> 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.
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.
It was in a location where it didn’t take up any space. Now it’s consuming a massive amount of space.
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.
There’s nothing better about the wasted sidebar column.
That’s my biggest gripe anyway. I much prefer a centered design for the site.
This is getting cliche. With any modern UI redesign you can immediately guess what’s changed:
Removed/reduced visual separation between elements
Flattened things more
More padding
Modern UI designers are strikingly unoriginal.
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.
JUST STOP CHANGING THE UI FOR NO REASON!
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 want boring interfaces that work, make information easy to find, and help me get my job done.
Designers have boring jobs under this regime, this their need to create unnecessary work and pain for users.
There should be a Wirth’s Law for UI:
UI design is getting whitespace padding more rapidly than screen resolution is increasing.
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.
You don’t have to redo the entire UI to implement dark mode. Just change the color scheme.
I always look for the light mode button in this new hipster software.
Next thing I know, books will printed white-on-black.
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.
For me, the mobile experience is illustrative. Look at the screenshot examples there:
https://twitter.com/greatgib42/status/1275703359283122183?s=…
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.
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.
I’m pretty sure I read somewhere that at least 50% of the vms running in Azure are actually running linux.
And in this case, “action” refers to the ci/cd tooling github provides called “github actions”. It’s one of the tabs at the top.
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.
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 guess people with huge displays don’t mind…
I use a ultra-wide (2560×1080) 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
[1] https://imgur.com/FNs1qb6
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.
This was my first thought as well.
A menu that uses the entire space, but then something in the middle.
It’s just weird.
I really don’t like this change and I’m pretty open to it normally
So much of modern design seems to be more about / for the designers than the users or UX.
Maybe they need a good introspective period in their art, or some psychology classes?
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?
I know obviously files are important in GitHub, but for the opening page of a random repo I think I would actually prefer to see the README first.
I just went to the Explore page and picked the first repo:
https://github.com/johannesboyne/gofakes3
You have to scroll so far down to find out what the project _actually is_. I know there’s an about message on the right, but it’s not great.
The new UI does look more modern, but there could definitely be some improvements.
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).
I find that the code helps me get oriented, like running ls in a project’s directory after cd-ing to it.
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.
Agreed!
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.
It’s where a lot of projects keep their binaries, appended to releases. They’ve made it harder to get to.
Highly dependent on how I got to the repo.
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.
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?
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.
Some examples:
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.
Not discounting your experiences but I really have not found any of what you described as a problem.
Except for the very prominent clone button, I really have not felt it has brought anything negative.
Although, I probably use GitHub like 50% less than you.
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.
It gets merged into MS product catalog, GitHub might have a time table at this point…
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 change.
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.
Agreed.
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.
What’s sad? Actually, you can find the classic (good) github design alive and well in China: https://gitee.com/drinkjava2/frog
Sorry tangential, but what’s this frog neural network project? Looks fun!
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.
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.
Wow, that’s pretty bad. Logical consistency was clearly not a guiding principle of this redesign.
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.
For sure we can all learn through trial and error pretty much any UI. And I know there are complaints any time any big site tries to do a redesign.
But a good UI should be intuitive for a first time user. This seems objectively worse.
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
The grayscale reduction and loss of contrast is a modern design anti-pattern they have adopted. Makes reading things more difficult
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
I selfhost gogs and like it. And the releases link is at the top like many ppl wish here 🙂
Only thing I really miss vs. github is there’s no code review built-in.
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.
I really don’t get what’s all the fuzz about.
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.
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.
Did you check it on mobile or desktop?
I like the mobile version, however I dislike the desktop version with elements scattered all over the screen.
> …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).
Reminds me of sr.ht who just straight up make every link blue + underline, on the scale of design effectiveness it already beats 99% websites
They destroyed the one thing Github had over alternatives (like gitlab). An easily findable releases section.
There’s are large release section at the top of the right column. It’s given more real estate now than the simple link that was there before.
Previously it was at the top in the same row as Code, Issues etc.
Now without scrolling it is at the bottom right corner.
They also placed the ‘About’ on the side bar which of course messed up the mental model for lots of Github users, judging by the comments here.
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.
This is my largest complaint (so far), since it was something I was looking for on a project just after the release.
