Ask HN: Thoughts on new GitHub layout?
I think it feels like Jira and I'm really sad. Seems more like a MS move than a GH move...
Migrating to gitlab...
Migrating to gitlab...
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.
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.)
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.
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.
The number of broken master branches I’ve seen on Github is astounding. So I find the CI status indicator to be very useful.
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.
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.
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.
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.
If they're pushing for that, then keeping the README below the file list seems counterproductive.
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.
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.
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.
They be building Norman Layouts at GitHub
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.
Google did us a favor and made an awesome Golang client library specific to GitHub
I don't expect companies to take on my feedback. I do expect them not to treat it like it's a joke.
You destroyed much of the trust I had. Will you roll this back and reconsider after talking more of your user base?
I changed 2 things and that's the result:
https://i.imgur.com/RU0rsAO.png
Disable:
`border-top: 0 !important;`
from .border-top-0
Set this class to this value:
.color-blue-3 { color: rgba(3,47,98,.5) }
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.
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.
SCRIPT1053: Const must be initialized
SCRIPT1014: Invalid character
SCRIPT1010: Expected identifier
SCRIPT1003: Expected ':'
Shipping more modern EcmaScript versions than what's supported by IE has lots of advantages for users whose browsers can support it, so I'd hate it if the IE support came with the expense of everyone else's experience. There are ways to serve different JS bundles for different browsers, of course, but that comes with a maintenance cost for them.
Weird though that some buttons wouldn't work at all, because at least most of the basic functionality seems to work fine with JS disabled even. Maybe they should just disable JavaScript altogether for IE and it'd work better. That should be easy to implement too.
I'm sure as I get use to the new design I'll be able to navigate without much issue, but still figured it's good to share with ya.
Thanks for gathering feedback!
Nat drive-by commented on a non critical comment. Did not address our main concerns. Did not say anything like "let us take all this in and come back with something articulate" either...
Definitely feel like Nat and GitHub are actively ignoring is at this point
It'd also be nice if you could have the bar at the side up top, or shrink it a lot. It takes up a quarter of the screen space plus padding and margin. For reading README.md files and Awesome Lists, it's extremely intrusive.
Alternatively, you could have the README.md below the longer element of the new "sidebar" and the file list, so that it can take up the whole width of the screen.
I hope you read this!
Here's my input. Maybe it's useful? I don't know.
When the browser window is that wide (for FF anyway), the whole layout seems to line up well.
When the layout is wider than that (eg full window width), there is unbalanced white space all around.
I have to use CSS to remove empty gaps on both sides.
If there isn't you've done a tremendously bad execution job and no testing.
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!! :)
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 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.
Overall, seems like change for the sake of change. Boo.
Example: https://twitter.com/JahedDEV/status/1275532988772683776
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.
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.
It's 30cm/1ft between the Issues button and the main table.
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."
You really need CSS that accounts for resolution and pixel density these days.
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.
:root {
--width: 1600px;
}
.container-xl {
max-width: var(--width);
}
.pagehead {
padding-left: calc(50% - (var(--width) / 2));
padding-right: calc(50% - (var(--width) / 2));
}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)
.col-md-9 {
width: 100%;
margin-top: 1em;
}
.col-md-3 {
width: 100% !important;
margin-bottom: 1em;
}
.flex-md-row {
flex-direction: column!important;
}
.flex-md-row {
flex-direction: column-reverse!important;
}
.BorderGrid--spacious .BorderGrid-cell {
padding-top: .2em;
padding-bottom: .2em;
}
div.BorderGrid.BorderGrid--spacious > div:not(:first-child) {
display: none;
}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.
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.
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.
It seems to me Github from the Microsoft acquisition is going into a wrong direction.
Honestly - pretty refreshing, designers typically forget to test on low end monitors - not high end ones!
new:
https://github.com/torvalds/linux
old:
https://web.archive.org/web/20200619163555/https://github.co...
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.
https://web.archive.org/web/20130807124247/https://github.co...
https://web.archive.org/web/20170924075025/https://github.co...
what website did you think you were on?
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.
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.
It doesn't work properly on small phones. On my Moto G5 plus, on a repo's home screen, 3-digit "last commit dates" don't fit in the space available.
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'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.
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".
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.
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
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.
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.
Old: https://web.archive.org/web/20200619163555/https://github.co...
New: https://github.com/torvalds/linux
It was always strange to have all the language info at the top
Or just add
* {
border-radius 0 !important;
}
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.
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's my biggest gripe anyway. I much prefer a centered design for the site.
The side bar is one reason I dont use GitLab.
* Removed/reduced visual separation between elements
* Flattened things more
* More padding
* Added dark mode
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.
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.
New GitHub looks alright on low resolutions, but looks kinda awful on big screens. This is the opposite problem old GitHub had.
Next thing I know, books will printed white-on-black.
UI design is getting whitespace padding more rapidly than screen resolution is increasing.
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.
Designers have boring jobs under this regime, this their need to create unnecessary work and pain for users.
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.
This practice should be applied universally throughout our lives in every field, perhaps except Art where creativity is revered and the avant-garde prevail.
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.
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.
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."
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.
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?
Maybe they need a good introspective period in their art, or some psychology classes?
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
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
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 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.
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.
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.
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.
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)
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 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.
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).
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.
* "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.
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.
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.
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.
- 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 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.
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.
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
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.
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.
Not complaining about the design of the new languages section, but the layout is just completely terrible and useless.
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.
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 found and modified a Firefox user style to fix the alignment for wide windows.
Original mozilla userstyle: https://gist.github.com/healingbrew/acc65ad439379eabdbb276e8...
Modified stylish chrome extenstion userstyle: https://gist.github.com/montanaflynn/ca64cc0fcf55bcd4556a016...
I use this regex so it doesn't apply on the full width logged in homepage or /notifications:
https:\/\/github\.com/(?!notifications)(.+)
Before: https://imgur.com/3ogzYhI After: https://imgur.com/8zMwTLL
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.
Only thing I really miss vs. github is there's no code review built-in.
Since many different organizations self-host GitLab instances (which is great!), having to enable Javascript for each one can be a bit of a pain.
But a good UI should be intuitive for a first time user. This seems objectively worse.
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 really don't get what's all the fuzz about.
Overall a positive change since the pages are loading faster for me.
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.
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.
you made my day! thanks
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.
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.
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).
That used to be front and center and two of the most important things when I land on a repo page.
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.
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)
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'.
Could you elaborate on this?
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
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 gave some negative feedback about it earlier regarding this change, but it seems I might have been a part of the minority.
Really love that they ignored it...
They know UX for sure!
Maybe we should send them a copy of Don't Make Me Think
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.
Also show latest release link with summary.
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.
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.
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].
Discussion on /r/github: https://www.reddit.com/r/github/comments/hei81f/
Personally I think it's an improvement on mobile - finally the entire README is readable by default.
That being said was there any warning/reasoning behind the change? I cannot find any announcements.
I had a "Preview: Try the new layout and give us feedback" notification for about an hour, then it switched on permanently.
Optimistically, maybe they accidentally flipped a trial feature flag globally and it wasn't intended?
It's more telling that they didn't listen and pushed it out so quickly anyway.
...because usage of Github from mobile is so important /s
Still prefer that to this update
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.
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.
---
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.
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.
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.
The vast majority of the time I arrive at a git repository is because I want the source.
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
- 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.
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 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...
Edit: today I learned a lot of young people sound like old people. Interesting perspective.
The way the top tab/nav bar stretches across the screen, while the content is centered feels broken to me.
https://twitter.com/joelkesler/status/1275557934290755584
(above) I mocked up what the repo screen could look like if it used Github's previous UI with the new layout (and fixed the fluid tab bar!)
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.
Fortunately it's easy to use a little custom CSS to revert them to square images, at least for now:
https://gist.github.com/jmarshall/a880c93725ee727abb54473582...
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.
>...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.
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
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 can't relate to the OP's preference for Gitlab's UI. Gitlab UI is the reason why I don't use Gitlab.
I do not like Jira, and if GitHub starts to be Jira, definitely looking elsewhere.
GitLab seems like the next best option. Any other suggestions welcome too!
The top-level hierarchy is different and causes much more wasted space
Your justification for bad redesigns is that... other companies do it too? That's a very apathetic/defeatist attitude.
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 do like that sponsors appears more prominently; for a very long time financial incentives have been an unsolved problem in open source.
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.
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?
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.
Like "hey lets get rid of the eye guidance thingy, so it looks less like a table?!"
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.
And of course in the quest to re-skin everything for no reason, important things like last commit message and status were removed.
Other things aren't so bad but I don't think they make up for breaking the general alignment in such an obvious way.
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?
The "About" being moved to the right side is a good move, but the top bar being full-width is incredibly annoying.
If this is any taste of things to come, then I imagine I'll be moving to Sourcehut permanently earlier than I thought.
I'm thinking of moving just to support another COSS (Commercial OSS) company. https://coss.media
Did a quick jumble of the html and css to things I would prefer: https://imgur.com/a/1HEROxa
Not perfect but I like it more than what they went with.
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?
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.
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.
People hate websites that look like they were designed by a programmer. Programmers hate websites that look like they were designed by a programmer
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.
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.
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
The livesearch loses focus, then selects the whole item if you pause for a second. If you then continue, the search is borked.
If you search fo something in an organization, the next time you try to search it searches the whole site.
.repository-content > .d-flex { flex-direction: column !important; } .repository-content > .d-flex > * { width: 100% !important; padding-left: 0 !important; padding-right: 0 !important; } .repository-content > .d-flex > :last-child { margin-top: 2rem !important; } .Box-row:not(:last-child) { border-bottom: 1px solid #e1e4e8 !important; }
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.
I’ve admired Github for having a clear and readable UI that didn’t change. All their UI feature additions before I thought were fantastic.
Devs don’t want to have learn new things if not necessary. I’m hoping it will grow on me.
javascript:void(document.getElementsByClassName("gutter-condensed")[0].childNodes[3].after(document.getElementsByClassName("gutter-condensed")[0].childNodes[1]))I'm not sure what was wrong with the old design. Now everything is too rounded and flat and there's not enough contrast.
I also liked GitHub better years ago when the top bar was not black, so yeah I can hold a grudge :)
the UI is truly responsive now. that's what i care most about.
they finally made it possible for me to read code at my specified zoom level. it's something that i struggle with on a daily basis on many websites.
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...
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.
> Migrating to gitlab...
Wow, some serious "looks like JIRA" PTSD there. Did Gitlab promise they wouldn't redesign?
Upcoming https://gitly.org is going to have a similar design, even simpler.
It's written in V, so it's very light and fast. Open source release this week.
Other features (from the readme):
- Minimal amount of RAM usage (works great on the cheapest $3.5 AWS Lightsail instance)
- Easy to deploy (a single <1 MB binary that includes compiled templates)
- Works without JavaScript
- Detailed language stats for each directory
- "Top files" feature to give an overview of the project
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.
That's usually the first thing I read. Then I dive into one or two files to check things out.
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.
* 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 am not affiliated with Source Hut in anyway other than being a satisfied customer.
1. Not being able to click to a repo home page if you are on a nested page, or link to a file from the web etc.
2. Markdown files displaying in raw form when someone links to a ReadMe.md file directly etc.
UPD: Nah, it can't handle it.
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.
However, I do like the visual part of the new layout.
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 non-centered readme is a little triggering, but maybe I just need to get used to it
Kinda interesting. But beyond a README, I can't imagine making any significant edits this way.
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 !
Everything looks great so far, so kudos for everyone involved.
- removed all the rounded edges
- added lines dividing the rows in the files table
[0] https://chrome.google.com/webstore/detail/stylish-custom-the...
I do wish there was an option to use more screen-width, and this does seem to be a step in that direction.
Wish they had kept the description and page URL top and center.
And at least made the tabs and badges area the same width as the content. I bet they'll eventually come to their senses about that.
In that case, I submit that good design doesn't exist. I've never seen a major redesign that wasn't widely complained about.
There are valid complaints about this. I rarely complain about website design, and this time I am compelled to criticize it.
Other than those two, everything else seems OK.
It completely destroys typical page parsing habits.
The header thing must be a bug, I can't imagine that won't get fixed.
Jira has this, thus my association and triggering ;]
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.
Functionaly, I'm having trouble finding things. Half of it is just because it's new but honestly some of it is due to stretching information apart.
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.
New version displays them all.
Thank you.
Thank you for not disappointing.
The navigation aligned on the left and the main section with code centered is so unbalanced it makes me nauseous.
Was there a reason other than "it's 5 years old"?
Please add a TOC Feature! Use what you have with github pages and Markdown!
The new layout has soft boundaries between boxes that make it harder mentally to distinguish one box from another.
Also, on mobile I'm not really sure how to go directly to commits to master.
Edit: figured it out...
So much wasted space and loss of information if you ask me.
- information is scatter everywhere - release is a lot hard to find - UX is bad on wide screen. I use a 32:9 49" monitor and it's pretty bad.
Like scroll down a readme, is all that space on the right better usage?