That's an interesting choice of rollout if you enable it for all users that see your repository instead of enabling the view for yourself for all repositories that you browse.
I would imagine that it is easier on Githubs end to configure a repo to render one way or another rather than to conditionally render it based on the current user.
I just got a notification/alert at the top of the site saying something to the effect of "would you like to try out our new layout?" yes please. voila.
It was there for me, just a prompt at the top with a short message and a green button. A quick reload later and there it is. Staggered roll out I suppose.
I would like that. For comparing many software projects I sometimes use "how complete is the Twitter profile" as a metric, just like a lot of people use "how does the website look".
One software project that I've been involved with for over a decade still uses the same old stale graphics, and it's basically telegraphing the fact that the SABDFL is not big on letting other people contribute to areas he's not comfortable with.
It took me ages to get used to the old new design (that dropped the tabs on top). Glad they're switching back... definitely a more intuitive structure for me.
The second picture, probably one of the earliest interfaces of GitHub (??) reminds me of Sourceforge, in fact, the horizontal navigation exists in Sourceforge.
I guess keeping things more center benefits interaction.
Interesting changes, seems like the trend of pulling items out of icon-based menus and into persistent nav is gaining speed.
I'm not sure how I feel about the full-width pages yet.. easier to read commit messages but stylistically I did like the icon menu on the side. The narrower version also seems ever-so-slightly easier to read, but it's hard to say without trying it first. Looking forward to demoing once the roll-out starts.
I hope the removal of the sidebar doesn't result in wider README views.
The current design has a fixed width of 790px (including 30px of padding on each side), which leads to a comfortable number of words per line. I find readability much worse when line lengths get longer.
Other than that, I think the simplified navigation is a big improvement.
I think it's that the sidebar menu is not present anymore (on the right hand side). Usually in this view it is the icons only, so pretty narrow anyway.
I'm holding my thumbs for a GitHub with a responsive layout. The separate mobile site is pretty nice, but it lacks tons of functionality (and it's hard to access on non-mobile).
Ha, yesterday I counted the number of words and/or links they fit onto a mobile page. Forty! The page is almost all whitespace. Sweet, margin-padding whitespace.
I had never noticed before that GitHub "Highly Recommends" cloning via HTTPS instead of via SSH. This is the opposite of what I usually tell people to do. I do not see any reasoning anywhere, but I might have missed it.
Does anyone know why you would recommend HTTPS over SSH? Is it just the complication of setting up SSH keys?
Yes, they've explained elsewhere that they prefer HTTPS because you can use your GitHub credentials. HTTPS should be secure but SSH is my preference as well.
I can think of one possible reason: if you have a passphrase on your SSH key (which GitHub recommends in their keygen tutorial) then pulling from a repo will require you to enter your passphrase, which is somewhat silly if you have some remotes that you only pull from and never push to (and of course you can set up different remotes for pushing and pulling for the same alias, but I've rarely seen that done).
> This is the opposite of what I usually tell people to do
How come, out of interest? In terms of peformance, cloning for HTTP is fairly efficient these days although I would concede an authentication argument.
(As an aside, SSH can be blocked on some corporate networks)
Because you don't have to keep supplying credentials when using SHH keys. It's less about speed and more about reducing the friction in common operations. It's also the way I'm used to handling things with gitolite, so that might be part of it.
We already usually use SSH w/ keys for server access, so uploading public keys to GitHub isn't much of an additional hurdle.
You can setup a credential manager in git and don't have to continue supplying credentials with HTTPS repositories. For instance, I commonly use this one on Windows [1]:
[1] Although currently marked as pre-release, this is a fork/successor of an earlier one that was fairly rock solid, now with a better installer. The "pre-release" tag here mostly is with respect to the new 2FA support.
Thanks, but this seems like a lot more complexity than using github's built-in SSH Key manager (especially since I wager that most people using github are not on windows). That, and I've inevitably always needed SSH keys for one thing or another on every computer I've used, so it's just really streamlined.
As with most such things, your mileage will of course vary. There are credential managers out there for things like the the Mac OS X keychain and Gnome keyring.
So yes, if you've already got SSH keys in play and you aren't dealing with (corporate) firewall issues for SSH protocols then that is often going to be convenient, but the point is that credential managers are out there and are equally convenient (work just like the ssh-agents you rely on) for those (stuck) with HTTPS or who don't need SSH keys anywhere other than git(hub) repositories.
Also, I'd almost take that wager. There are a lot of Windows developers these days on Github and/or Github for Enterprises. I don't think Windows developers have made it into a majority yet, but I'm guessing there are a lot more than you think there are.
I always recommended ssh until trying to use gitlab for a class I teach to nonprogrammers... and the extra complication over https was immense. Lots of github's users have never used SSH before and those that are comfortable with it probably aren't going to pay attention to github's recommendation anyway.
They wanted more repository content above the fold. Turns out having discoverable and clear navigation is more important since the vast majority of the content (e.g. readmes) is going to be displayed below the fold either way.
Wow I totally missed that, I wouldn't say that it's very good UX considering that it doesn't intuitive for many, with the dropdown it's obvious that you can switch.
Yeah, the only way I ever found it was because I kept accidentally doing global searches when I though I was searching a repo. Turns out I just held backspace too long while clearing out the search bar. It took me a long time to realize what was going on.
There's one part of the GitHub UI that I still wish they'd change: the way "contributions" are displayed.
Right now, there are accounts that seem to just fork a bunch of repositories and then do nothing with the forks. This makes those people look like massive contributors to open-source because GitHub gives them a nice "Contributions" tab with a list of popular projects under it.
They also get free advertising in reverse because they automatically appear as a "Member" of the parent project's network, despite having done nothing at all in the project!
At the very least, GitHub should require the forking person to have made some pull request that was accepted. If those forks aren't actually contributing, they shouldn't even be mentioned as a sub-network of the original (except perhaps as an option for the project maintainers to see, if they're curious where forks have occurred).
Yes but if you go to "Members" you see all of them, which is confusing at best. The term makes it sound like this is a list of people who are members of your project, when they're not.
And for something like the Linux kernel, it's not hard at all to find people who are about 236,000 commits behind the master.
I agree that GitHub has some accurate views but they're all mixed and it's very easy for a list to look like something that it isn't.
I think @makecheck is talking about forked repositories showing up on a user's public account page, making them appear to be contributors to jQuery or NodeJS because they forked the repo instead of starring it.
I've seen tons of this. People forking popular projects and making minor pull requests to correct spelling or change formatting, probably so they can pad their github profile (which we're told is the new resume) and make it appear as though they're highly-active and are contributors to major projects.
If someone were forking my project to even fix a single tiny whitespace issue or typo, I'd be happy! They generally do nothing though. It seems like 90% or more of forks result in absolutely no changes whatsoever.
I kind of wish a fork wouldn't even trigger notifications or be listed on any pages until at least one commit is made to it.
Most GitHub forks are because people don't understand how git refs work. I used to work at a company that required us to fork every repo we depended on and lock our dependency to the fork rather than using a package manager and git refs.
> On 19 August 2009, why's accounts on Twitter and GitHub and his personally maintained websites went offline. Shortly before he disappeared, why the lucky stiff tweeted, "programming is rather thankless. u see your works become replaced by superior ones in a year. unable to run at all in a few more."
Is there a good way to 'deep' browse GitHub? I love just browsing through repos by language, but I have found that this is limited to a max of 500. Once you get to 500 there is no way to get to 501, etc.
You can random walk the social graph as deeply as you want to: click on a contributor to a repository, then explore a repository they've also contributed to, then click on a different contributor in that repository, ad infinitum.
Depends on the language. Some languages the core contributors are active enough across the language that you can get a very wide view of the projects happening in that language. Certainly it will never be as efficient as a flat list, but it can still be useful for finding interesting things.
I never liked the side navigation, we stayed with top one in RhodeCode from beginning and imho it works much better, and i say no for putting icons on everything.
77 comments
[ 3.8 ms ] story [ 132 ms ] threadOne software project that I've been involved with for over a decade still uses the same old stale graphics, and it's basically telegraphing the fact that the SABDFL is not big on letting other people contribute to areas he's not comfortable with.
Arguably it's a nicer look with some UX benefits.
[1] - https://camo.githubusercontent.com/fec1c4ab93659e759682ad5db...
[2] - http://cdn.appappeal.com/pictures/6089/screenshot.png
I guess keeping things more center benefits interaction.
I'm not sure how I feel about the full-width pages yet.. easier to read commit messages but stylistically I did like the icon menu on the side. The narrower version also seems ever-so-slightly easier to read, but it's hard to say without trying it first. Looking forward to demoing once the roll-out starts.
The current design has a fixed width of 790px (including 30px of padding on each side), which leads to a comfortable number of words per line. I find readability much worse when line lengths get longer.
Other than that, I think the simplified navigation is a big improvement.
Some extra margin on each side might be nice.
Otherwise, a nice incremental change.
Even HN is responsive these days!
Does anyone know why you would recommend HTTPS over SSH? Is it just the complication of setting up SSH keys?
[0] https://help.github.com/articles/generating-ssh-keys/
How come, out of interest? In terms of peformance, cloning for HTTP is fairly efficient these days although I would concede an authentication argument.
(As an aside, SSH can be blocked on some corporate networks)
We already usually use SSH w/ keys for server access, so uploading public keys to GitHub isn't much of an additional hurdle.
https://github.com/Microsoft/Git-Credential-Manager-for-Wind...
[1] Although currently marked as pre-release, this is a fork/successor of an earlier one that was fairly rock solid, now with a better installer. The "pre-release" tag here mostly is with respect to the new 2FA support.
So yes, if you've already got SSH keys in play and you aren't dealing with (corporate) firewall issues for SSH protocols then that is often going to be convenient, but the point is that credential managers are out there and are equally convenient (work just like the ssh-agents you rely on) for those (stuck) with HTTPS or who don't need SSH keys anywhere other than git(hub) repositories.
Also, I'd almost take that wager. There are a lot of Windows developers these days on Github and/or Github for Enterprises. I don't think Windows developers have made it into a majority yet, but I'm guessing there are a lot more than you think there are.
Unless I missed something, the only way to search globally now is to go to github.com and then use the search bar.
You can delete the default "this repository" facet. Just hit backspace when you're in the "local" search: http://giphy.com/gifs/l41lJC4ZrO3sEFuNO
Right now, there are accounts that seem to just fork a bunch of repositories and then do nothing with the forks. This makes those people look like massive contributors to open-source because GitHub gives them a nice "Contributions" tab with a list of popular projects under it.
They also get free advertising in reverse because they automatically appear as a "Member" of the parent project's network, despite having done nothing at all in the project!
At the very least, GitHub should require the forking person to have made some pull request that was accepted. If those forks aren't actually contributing, they shouldn't even be mentioned as a sub-network of the original (except perhaps as an option for the project maintainers to see, if they're curious where forks have occurred).
The project is included in a user's "Repositories contributed to" area when that user creates a pull a pull request or files an issue.
You are listed as a contributor on a project's page only once you have had an accepted pull request.
EDIT: take one of my projects for example[0] - 152 forks recorded but only 8 people are listed as contributors.
[0] https://github.com/stonesam92/ChitChat
And for something like the Linux kernel, it's not hard at all to find people who are about 236,000 commits behind the master.
I agree that GitHub has some accurate views but they're all mixed and it's very easy for a list to look like something that it isn't.
https://github.com/stonesam92/ChitChat/network/members
It lists all people who have forked instead of only contributors. The 'members' tab in general doesn't appear to make much sense.
I agree, that could indeed be misleading and doesn't seem very useful!
I kind of wish a fork wouldn't even trigger notifications or be listed on any pages until at least one commit is made to it.
> On 19 August 2009, why's accounts on Twitter and GitHub and his personally maintained websites went offline. Shortly before he disappeared, why the lucky stiff tweeted, "programming is rather thankless. u see your works become replaced by superior ones in a year. unable to run at all in a few more."
https://en.wikipedia.org/wiki/Why_the_lucky_stiff