A new look for repositories | Hacker News Reader

A new look for repositories

github.com

176 pointsobilgic76 comments

Ha, they're going back to the way repo tab navigation used to work a long time ago, with the tabs on the top, like [1] and [2].

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

and then when they decide to add new Menu Items and run out of space, they will switch back to the Sidebar :D

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.

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

You don't become listed as a contributor by merely forking a repo, your fork is just included in the original project's "forks" count.

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

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.

For anyone curious on how to get there:

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.

Ah, I'd never seen the "Members" tab until you pointed it out.

I agree, that could indeed be misleading and doesn't seem very useful!

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.

This prevents you from getting _why'd, so it's pretty reasonable.

For those that don't understand the reference:

> 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

On the other hand, you're now safe from users who don't understand how `git push -f` works.

Yes, I've noticed a lot of do-nothing forks too.

Eh, 1 character or 1,000 lines of code, contributions are contributions and should be acknowledged.

The nature of the contribution is fully transparent in the commit history, so not a problem. Anyone employer who doesn't bother to look...

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.

It does feel a bit wide to me, but I haven't tried it yet.

Some extra margin on each side might be nice.

Yea I was worried about the same thing, I've tried it and it's a tad different. Give a few days I think.

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.

In addition to corporate firewalls, it isn't uncommon for all ports other than 80 and 443 to be blocked in public wifi environments.

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

I much prefer to use an ssh key for auth than copypasta'ing the same passphrase I use in my browser.

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]:

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.

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.

SSH is blocked on some corporate firewalls, they've said before that they've implemented HTTPS support to get around this.

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

Their tutorial[0] also recommends using ssh-agent which means you'll only need to enter your passphrase once, and it integrates with your OS keychain.

[0] https://help.github.com/articles/generating-ssh-keys/

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.

For example - ports other than 443 and 80 are more often blocked.

I wish they reverted to the old search bar, where you could chose to search globally or just the repository you're on currently: https://github.com/blog/1492-repository-search-on-all-reposi...

Unless I missed something, the only way to search globally now is to go to github.com and then use the search bar.

> 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

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.

It definitely has terrible discoverability. Same as the file Find As You Type (hit `t`, type bits of a filename).

And keyboard shortcut is `s` then `backspace` to do a global search.

Nice, thanks for the demo! I take back what I said, this is better than the old version with the dropdown.

If you press the delete/backspace key when you focus the search box, you can search globally from most pages.

Oh wow, can't believe I haven't tried that all this time! I'm glad I complained now :)

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

Even HN is responsive these days!

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.

Well, you know minimalist design is all the rage these days.

Interesting. This is closer to the older UI, before they rolled out "Repository Next" - https://github.com/blog/1529-repository-next

Will be interesting to compare the comments here with those of 2 years ago: https://news.ycombinator.com/item?id=5894438

And bookmark this current thread for when they reintroduce sidebar navigation in 2017. :)

I don't see how to opt-in, where's the button?

I don't see it either, maybe they're bucket testing, odd that they'd announce it if that's the case ...

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.

This does not allow you to efficiently browse by language.

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.

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 was almost expecting them to let us add a header image to our repos, the way Facebook Google+ and Twitter do.

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.

Says it's opt in for the next two weeks, but I'm not seeing how to opt in.

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

I guess they are slowly letting users opt in. Seems incredibly weird and slow considering the public featured announcement on the blog.

It says over the course of the next two weeks, you'll be able to opt-in so its being slowly rolled out.

Don't see it either. Maybe badly worded.

@mdo said they're slowly rolling it out, and when it's available then you'll be prompted on the repo you own.

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 never understood why they changed it, but I'm glad it's back.

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.

If someone wants to keep the tabbed nav sticky to the top of the page, I wrote a Firefox add-on / Chrome extension to do so: https://github.com/tonglil/github-static-nav

I don't get what is different in third screenshot.

Otherwise, a nice incremental change.

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.

The sidebar with label/milestone etc is slightly larger to fill out the space from the navigation being moved up.

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.

Reply on news.ycombinator.com