

Github's new look: The Code Tab - latch
https://github.com/blog/958-the-code-tab

======
latch
I like it. But...

The download button is a step backwards. First, I had to search (cmd-f) to
find it. There's plenty of room under "stats & graph" for a more distinct
button. Secondly, the tab it brings you to makes it look like there's nothing
to download. Look at:

<https://github.com/mongodb/mongo/downloads>

The text makes it seem like an error almost..then I saw the buttons.

~~~
kenneth_reitz
Note the new ZIP button next to the Git URLs.

~~~
gurkendoktor
The link placement is still a step backwards when there are actual files
uploaded, e.g. binary builds. And I would argue that the new ZIP button
doesn't make it easier for newcomers to find those ZIP builds. I wish there
was a way to make downloads really obvious for those projects that rely on
them, this is still something I miss from Google Code.

------
xbryanx
Really happy that they've made branch switching easier. It was a pain in the
previous version.

------
MatthewB
I really like it. As a github newbie I think the new nav bar layout is much
cleaner, especially the commits/branches section. Well done.

------
gyardley
Maybe I'm getting old, but could the numbers in that new nav bar be any
smaller?

I used to be able to tell how many open issues there were without squinting.

------
overshard
The new nav bar seems out of place with the rest of the design. This might
just be me, since I've used GitHub for a few years now, and I'll get used to
it but maybe this is leading to more changes in the future. I, for one,
welcome our new cleaner design overlords.

~~~
alanh
No, I’m completely with you. I’m hoping for greater consistency soon, e.g., no
more blue-on-hover buttons.

------
grandalf
Looks awesome! Does the "open in mac" button show up even if you don't have gh
for mac installed?

~~~
telemachos
I'm not sure if this is what you mean, but here's what I've found: If you
install GH for Mac on any machine, the "Clone in Mac" button shows up
afterwards on _all machines_ , no matter where you login from. So in that
sense, you can see the button, even if you don't locally have the app
installed. (I actually just sent a support request to see if this could
change.)

------
sunchild
Has that "Search source code..." input always been there? I sure needed it in
the past, and somehow never saw it until now.

~~~
gabebw
I assume you're basing this off the screenshot. The "Search source code" input
is only available in private repos. Since kneath/resque is a public repo,
apparently one benefit of working at Github is getting that input on all
repos, whether public or private.

------
BillSaysThis
Where is the 'search this repo' button/field?

------
jsavimbi
As much of a fan of Github that I am, their UX has always been confusing and
now that added yet another layer of complex navigation to the page.

They now have a total of seven horizontal navigation areas of which some are
mixed in with actionable items, along with the independent actionable items
spread within the navigation layers and content:

1\. User Nav 2\. Github nav and search 3\. Breadcrumbs and forking action/info
4\. The new code navigation bar 5\. Files/Commits/branches nav 6\. Main footer
7\. Informational footer

All of that in addition to the actual project content blocks, message display
and project byline.

imo, they could benefit from cutting back from all navigation that is not
pertinent to the project, merge the Github nav with the main and informational
footers, consolidate actionable items and non-code content (that new embedded
message bar) and lose some of the cruft. Yes, it's a tool for engineers, but
it's also a platform for learning and many people don't really need every
single url/action in the Github universe manifested on every single project
page.

~~~
kneath
Have you guys used the new interface? It sounds like you're coming up with
imaginary solutions that are already deployed. The nav does shrink up on many
pages, and every single update we've pushed out over the past 2 years has
brought the administrative chrome _smaller_ and the source code _up_

I'm happy to provide older screenshots for reference if you don't believe me
:) In a way it makes me really happy — people see more white space and assume
they've lost useful real estate. But the truth is they got more space and more
real estate.

~~~
jsavimbi
(I'm talking without any real analytics here; hopefully you took them into
consideration. Also, I'm not comparing the cli or the GitHub for Mac app. And
one more thing: I wasn't there when this app was a blank slate and I'm not
trying to beat you up on the UX, but it's time to count clicks and reassess
what needs to really be there.)

I think you're talking about the visual design and layout of the page. That's
a different ball of wax from the overall UX and doesn't carry equal weight, so
white space is not so much a concern of mine as I don't fixate on pixel
spacing enough to throw a fit about it. The design and the layout have always
evoked an immediate mental map based on the three or four everyday functions
that I need in order to complete my tasks on the page, and I'm usually
competent enough to complete my actions and end my interaction on the main
project page in short order. The basics are there, which is a good thing, and
the visual design itself is competent.

What bothers me is the multitude of mostly unrelated navigation systems that
are dispersed about the page with what appears to be a need to display all,
along with repetitive links strewn about. It suggests an underlying logic that
if an entity exists, it must be displayed. And displayed it all is in a very
unorganized fashion.

I would suggest trimming the fat and displaying only what the user needs in
order to complete their tasks and establishing a clear hierarchical visual
representation of global, project and in-page navigation and actions. There
are currently five different types of visual displays for navigation in the
top third of the main project pages alone: semi tabs, text links, breadcrumbs,
full tab buttons, folder tabs. The footers are equally disparate. Not all of
the seven nav menus need to be displayed in their entirety nor do they all
carry the same weight or deserve their own section of the page. That really
needs to be looked at and simplified before it grows even further.

The action buttons are all in a similar recognizable visual format, but they
too are also dispersed about the page without any obvious relation to the
content or navigation menus around them. For someone who's been using the app
for a couple of years, accumulated knowledge would overcome any new layout
changes (stop playing with the button placement, please) but to a new user,
you're basically throwing the kitchen sink at them and hoping that it all
makes sense. It's easy to transition a seasoned developer to Git, but Github
is another story.

Again, mine was not a critique of the visual design, but an honest assessment
of where the [creeping] overall UX is. Out of simplicity I didn't delve into
any of the project subsections or other sections of the website, but my
immediate thoughts are to migrate into simplicity and uniformity.

~~~
kneath
Yes, please use the interface. Again, you're describing solutions that already
exist.

This version of the navigation has the least amount of chrome out of any of
them, less buttons, less navigation all around.

~~~
jsavimbi
After reading the comments on the blog post and your inability to address even
the most basic of my concerns without invoking my imagination and your chrome,
both of which have absolutely nothing to do with what I've written, I think
today's improvement was not.

Also, you don't deserve to carry the brunt of the UX discussion on your
shoulders in a public forum, as you're obviously not the only party
responsible, but your enthusiasm is palpable and I commend you for it.

