Hmm, as someone who spends most of their time on github looking at pull requests and issues, this seems a step backwards.
Not a huge one, but it was nicer to have my most frequent points of interaction at the top. I deal with the code itself in my local repo. I don't need to know how many commits/branches/tags/contributors there are -- that is the redundant info for me, and that should have been shoved to the side.
If I'm using github's UI, it's because I'm managing a project. Might be nice to have a separate "management" interface you can opt into?
tldr: They moved all the "extra" stuff to the side, while keeping the info directly related to the git repo in the center. But the whole point of using github is the value they add, not the core functionality that I can already get through my commandline!
Does it also work when the syntax is outside of the diff context? I.e. think a html comment that started in an a prior insertion hunk? We had encountered a lot of edge cases whilst building the syntax highlighted diffs for https://www.tixef.com It is a tricky domain, hats of to you for attempting it in JavaScript!
The highlihght is pretty much constrained to diff (on pull requests, commits and compares[1]), but it could work on any page. I've mentioned[2] how I used jquery-syntaxhighlighter to do it, which itself is a fork of Google's Prettify in order to do the heavy lifting of syntax discovery and actual highlight.
I think their goal is the right; to reduce the vertical space usage at the top of the page before the "content". They did however remove some of the useful tabs and keep the least useful. Programming language stats and project description & project URL seems less important to me than the "code, issues, pull request etc" tabs.
Agreed. I've often presumed that stats (esp. language and commit counts, etc.) were part of the "social" aspect of GitHub, but not otherwise useful to me in any meaningful way most of the time.
I think the sidebars are a step back for me. I preferred some useful content at the top, now having it on a sidebar just moves that content to the right side, away from my focus.
One positive thing about the change is that "network" and "graphs" are now not co-mingled with main workflow items like Issues and Pull Requests.
+1
Also, how often do contributors look at the source code on github? Contributors will most likely have the repo cloned on their machine. I think if management interface were to exist, it should default to Pull Requests or Issues, or some kind of dashboard that summarizes new activities in both.
I find the source code view is particularly useful as a dashboard because it gives modification times at a glance for each sub-directory, so as a non-maintainer you can tell whether there might be anything of interest to pull down (and possibly reconcile with local changes), without needing to go to that directory on your disk and do the fetch on the command line. So defaulting away from that isn't an obvious solution.
>> replaced with a slim, de-emphasized icon-based navigation.
This is the same problem I had with a Gmail redesign a while back. Using icons looks nice and allows for slimmer navigation but it decreases ease of use for me. I can find things much quicker with text labels.
I have the same concern. I find it's even more troublesome with the flat/simplistic design aesthetic: it just takes way longer for my brain to differentiate one light-gray-on-white abstract symbol from another than it does to pattern match word shapes.
I've even turned on whatever Gmail lab puts the words back into the buttons.
My issue is that no-one should really have to 'remember' them.
When I first started using github it was straightforward as I only had to learn what the words meant (i.e 'fork', pull-request, etc). Now a new user is supposed to learn those concepts and their associated symbols. The cognitive overhead just increased.
It was pretty common during the 90s when screen resolutions were really low and preserving space was a big deal. We're seeing it again now because of mobile friendly responsive designs dealing with the same issue.
I'm curious how many people browse github from their smartphones. Right now I'm on my desktop and see a pretty column of unlabeled icons, right next to three inches of unused whitespace between the icons and the edge of the frame. It's a somewhat inefficient use of space...
That takes me back. The "Web Pages That Suck" book was what got me into web design and programming.
Unfortunately, while I bet almost all designers would recognize that mystery meat is bad in the classic 90's context of using it on a homepage, its become acceptable with these sorts of interior toolbars.
So while github is not using it on the project homepage - probably because they recognize it would be MM and be awful - they are using it deeper down.
The number of times I've hit GMail's 'Spam' button rather than 'Trash' is ridiculous. Whether due to the icons or the placing of them next door to each other with no visual (apart from icon or text-label) distinction...
Ok, as a dev who doesn't use github much, I'll give my best guess as to what those icons mean. Respectively:
Home
Alerts
Merging
Documentation
Interactive Heartbeat Sensor, presumably using my webcam, to notify authorities when I'm having a heart attack
Graphs
Branching
Settings
How close was I?
By the way, alt text is absolutely essential for screen readers to function. Don't exclude the blind if they have reason to use your site! Blind people definitely use Github.
I'll take a shot too. I don't use most of the fancy features on Github, so I have almost no experience with these things.
<> - code
! - warning / danger
|7 - merge a fork (or accept a pull)
E]E] - I think that might be a dictionary. Look something up?
_|^\_ - Heartbeat to let you know how active a project is.
|+. - Charts to see activity.
4 - Fork
>< - settings. Funny that it's a wrench and screw driver. Although I guess a keyboard and mouse would be a little less telling.
These seem bad because you can't get information about them before you interact. The icons are small, and kind of hard to make out (I had to turn my screen brightness up to see what was going on with that book one). But, once you get a little bit of experience with them (click them once), you'll have that icon (or just the order) ingrained in your brain. It sucks for people who aren't technical, or who are thrown into Github, but it's not bad for experienced users.
That is until next week when they decide they got the ordering wrong, and some of the icons wrong, and randomly swap and replace icons.
This kind of reminds me of the very challenging 'Is this thing I made hard to use for people who don't know what's going on?' It's a very hard problem - you, the creator, are designing and fabricating something that you want other people to use. You think you found a good way there, and you obviously found the best way because that's the way that you're going to build it. The path was obvious, we went from A to B to C back to B then to D, detoured to S for a while, didn't like the color sceheme, went back to D, then decided B was the best one. You have a lot of experience with alternate configurations, and have innate knowledge of how they work on the inside. Someone who comes up and uses D without any primer might be a little confused. Why do the colors matter here? Well, it's obvious, we went from A-B-C-B-D, it's a natural design evolution, ARE YOU TOO STUPID TO SEE IT!?!? You won't be one of my users... It's hard to distance yourself from what you're working on to see the flaws in your own design. It's very hard. It's easy to assume the knowledge you have, or the knowledge you as an organization have, will be present outside your group a priori. You don't know what they don't know, but you know what you know.
Regardless of whether or not you like the changes, Github has probably been following this 'design evolution' for a while, and they like where they're at, and assume you're smart enough to know beforehand what the icons do. Or, at the very least, smart enough to associate an icon with a topic related to git.
I have this problem all the time when using various minimal websites on my tablet. I can't mouse over for a tooltip, so if I don't recognize the icons I just have to start randomly clicking and hoping I don't end up being redirected to my mail app or something.
Finding the right balance between casual consumers of github and developers who live in it all day must be challenging, though.
EDIT: I didn't realize that the front page for a given repo shows text in the sidebar. Good on them, I like that compromise.
> Using icons looks nice and allows for slimmer navigation but it decreases ease of use for me. I can find things much quicker with text labels.
I believe studies have repeatedly shown that users can find things with icons faster than text labels. Icons are less discoverable than text, but once you know what you're looking for, icons are faster.
The 'discovering' part of discoverability isn't something that just happens one time. If I'm not using your software day in day out then I'm likely to forget your silly icons.
Yep; GMail adopting mystery meat navigation was a real step back, and it's still mildly irritating to use quite a while later. Hopefully this trend, if that's what it is, runs its course before it spreads much farther.
Aye, I really struggle with the greyscale icon menus everyone seems to think are super great these days. If they're in colour; fine, I can differentiate quickly enough. But both G+ and now GH seem to think very pale grey icons on a white background will be enough for people to distinguish them.
Honest question: Is Github supposed to be about Git and code?
Statement of opinion: It seems to me that Github is the leader of online code hosting. However, this position could be disrupted because, and I could be wrong, Github focuses on items not directly related to git and/or code.
I dream of a time when the average person making manuals or Stand Operating Procedures in an office environment can see the benefits of source control and has tools that make git easy.
The company that truly focuses on making Git itself dead simple and powerful will win. I pay github every month, but I am starting to lose my patience. I am actively looking to support a company that focuses on abstracting the completely unforgiving nature of git.
In my opinion, you shouldn't need to be a command line virtuoso nor need to grok the entirety of the git code base to use git. Eventually, everyone gets dirty with git and thats when the lack thought in usability exposes itself. Github could focus on this, but it seems like they have other priorities which is fine. I have mine too.
They help, but as a user of Github for Windows, I have too often been told that a "synch" (basically a combination of push and pull) failed and I need to resolve the issue using my command prompt. As an anecdotal measure, I would estimate this happens about 5 to 10% of the time while working alongside my colleagues who are not using Github for Windows, or any similar GUI tool, and using our own private Gitlab origin.
Github for Windows is also disappointingly lacking in functionality that is necessary in my workgroup. For example, it does not support Git submodules or two-origin configurations. When I work in repositories we have configured in that fashion, the command line is my option of choice. And let me be frank: there are scarcely any tools I use that have a worse user interface than the Git command line tool.
I agree with the grandparent that there remains a market under-served: to provide a decent user interface on top of Git. Github for Windows is amazing for a free tool and I give the development team a great deal of respect for what they have provided users like myself (people who want their source control and build tools to just do their job simply and get the heck out of the way). But there is a lot of room for improvement. I for one would pay good money for a Github for Windows "Professional" version.
Try Atlassian's SourceTree.[1] I have only used the Mac app. It's the GUI I settled on after trying three or four others, including Github (again, for Mac). They built the Windows client after everyone who uses Windows at work clamored for it. I'm still on XP though and it requires 7+.
Atlassian also has a good, friendly set of tutorials for using Git.[2] The order in which they introduce the concepts and the commands encourages a clear understanding of the whole system.
SourceTree has been great and Atlassian's support is also excellent. However, I still can't work out how to turn off Git's overly-optimistic automerge, which leaves << HEAD strewn through files at random.
I briefly tried SourceTree when the Windows build was first made available for download. However, it too did not support Git submodules--although from my understanding the Mac version does. I'll keep an eye on it though, since that seemed like something that would be added in time.
I am a firefighter and hobby/part-time developer. We have more manuals and SOP's than you can shake a stick at. They should be in source control so we can see how strategy and tactics evolve over time, who made the changes, diff's and/or allow "pull requests" from the field to change something for the better, as just one example.
Now, try to explain to your Chief or supervisor about how awesome Git is.. that is easy and I've done it. Then comes the part where you explain how to use it; The problem is the interface on both the CLI and GUI require a TON of "other" domain knowledge to use effectively. Abstract all that away at the same price point of Github and you will win a HUGE market.
We don't have IT budget to pay anyone to do this... nor buy the extremely expensive solutions that already exist. So we rely on email and ad hoc training to make sure everyone can stay abreast. Now, how many businesses not related to software development could benefit from Git or a similar DVCS?
That's a pretty interesting use case. I'm always interested in occupations with non-technical emphasis that are moving towards Git, GitHub, and source control in general.
I'd be really interested in hearing more about the problems you face, personally and within the firestation. If you'd like you can email me at my username [at] gmail.
Will do. Think about medical records or 911 call data in a git repo. This is evolutionary stuff that no one in the fire service is thinking about. Hell, our IT guru's can't seem to get clean data from one database to another. Its a sad state in .gov IT at the local level.
Hello Brother! Yes, we've used those... sadly they don't work "at scale." My department has 600 members and a lot of them have good ideas. They have to go through the chain-of-command to get those ideas heard. This method not only suffers from the telephone problem Ie. the idea is lost in translation. It also suffers from a Chief or Capitan not liking the idea(s) and never doing anything with it. Manuals and SOPs in a democratic environment where anyone could clone, make changes and submit pull-requests would be a manna from heaven.
In that case a Github wiki might be a good start. You get the version control, but there's enough abstracted away that it should be easy to get up and running with. Now, you just need everyone in your department to get a Github account...
Yeh, but the convenience of it here is that you may freely browse that repo (and change URL in the address bar), and still have the access to the repo URL.
You can clone with HTTPS, SSH, Subversion, and other methods.
Before I clicked "Enable Repository Next" there was also a "Git Read-Only" option.
The "other methods" text points to https://help.github.com/articles/which-remote-url-should-i-u... which lists HTTPS read-only & read-write and SSH read/write. Last time I looked that page also listed Git read-only (with the description "All git:// URLs are anonymous, public and read-only. Private repositories do not have this URL type. // Use these URLs when cloning someone else's repository (where you don't have write access) and for submodules that point at public repositories.").
There was no explanation in the "Repository Next" blog posting that git:// URLs were being disappeared...
Agreed. I use Bitbucket every day, and while it's far short of 30 seconds, I do find it takes a second or two of extra scanning to notice where the repo URL is. And it's essentially on the top right, not aggressively out of the way.
Now, Github's pushing it even further out of view than Bitbucket's location.
Yeah but by the time you've used the site a couple times, you'll be able to find the repo url from then on. It really doesn't make any sense being at the top of the page taking up so much prime space.
They added a green button which i assume is "fork on github". It seems they want to encourage people to use github rather to clone to local filesystem.
They've always had a quite prominent "fork on github" button.
Their suggested course of action is to fork on github and then clone to your local filesystem. You then push changes to your fork on github, and open a pull request from within their system.
The default workflow is designed to play nice with their issue tracker/etc.
Nope, that one is for pull requests. But they did disable SSH cloning for read-only and the cloning URL is not showing at all (only after you click on HTTPS), pointing towards preferring of forking.
The new design looks stunning next to the older one - which already looked good.
Am I the only one wishing the readme was above the file list? In my case, I often read the readme and rarely look at the files, and as a landing page standpoint it seems logical that the readme would be front facing instead of hidden at the bottom. I'm curious what's the reasoning behind that order, since it's been that way forever and GitHub seems to be fairly dedicated to elegant and thoughtful design while being open to change, I imagine there must be a good explanation.
That would be quite annoying with large READMEs. I could see it being useful the first time I view a project, but any time after that there's a good chance that I'd rather see the file list.
edit: It's for pull requests. When you enable the new design, you get a quick explanation of the green button and where the clone URL has moved to. So far I'm really liking the new design!
I really wish Github would bring back issues search and would stop making the top search bar default to the current repository. I constantly search something there and always forget to select "Search all Github". That being said, I think it's good that they are reducing the clutter.
Yeah, me too. It happens to me at least daily. I don't think I have ever wanted to search within the repository and it certainly shouldn't be default. In fact, I might write a browser extension to make it global by default again.
I don't mind the navigation being on the right, but the clone url doesn't appear on most repositories which is one of the most important elements of the repo.
search all of github is broken anyway. Half of my projects couldn't run with the language they choose to label it with. Unless you wade into the src, you have no idea what the repo actually is.
I wish there was a good way to search code. The input is filtered to be safe, which makes it really difficult to find a specific piece of code (especially when searching all of GH).
I know how it works, I just don't think it should work that way. I bet 95%+ searches on Github are Github-wide, not repository specific. Why not make the most common use case the default? Plus, why would a top navigation bar be context sensitive?
Interesting. I search within a repo (for code or issues) 95% of the time! It'd be interesting to know what their metrics are for usage of the search bar.
Ah, maybe I was just projecting my own usage patterns. A good middle ground would be for Github to display "All repositories" search results beneath repository specific search results.
Call me a Luddite, when a tool I use every day is completely redesigned, and marketed with phrases like "The content is the interface", I begin to shit my pants.
It's especially scary because there's no rollback. At least I still have gnome desktop, for now...
GitHub issues is another kettle of fish, but does anything force you to use the github interface to use the repositories? Forking, or making buckets?
You can host a copy of your repo on github, another on, say, bitbucket, and another on gitorious, and as long as you take care of syncing between them, you should be alright, right?
Fair point. I actually use Issues a lot, I find it great for small projects where I don't have the time or energy to set up bugzilla or trac etc. I like the way you can browse branches and commits, see your repos, start a new project with a README and so on. I can imagine using the wiki more than I have.
I just get this queasy feeling that this might be one of those over-thought reworkings, where they do everything they thought they would do years ago before the site took off. Sometimes that works, but usually it's a disaster. Incremental changes, with lots of feedback from real users, seems to be the better way for a site with a solid core of happy users to evolve.
I just switched over to the new design and I like it. My favorite part: no more silly horizontal sliding animation. Thank you so much for removing that.
Though--and I hate to sound ungrateful--Github has always seemed slow and unfortunately this new design doesn't help as much as I hoped it would when I read about it. I acknowledge that the new design is quicker, and removing the animation makes the wait for a response considerably less annoying, but Github remains a slow site to navigate. Put as positively as I can: thank you for working on performance, and please continue to do so.
This might be a nice update, I'll opt-int for some projects and try it out, but it doesn't address my biggest problem with GitHub: the lack of decent code review tools.
I have to use an external review tool like Reitveld to get side-by-side diffs and better comment and patch-set management.
Can't say I like the new look. The pjax improvements are great, of course. But moving all the top menus to a right-hand sidebar just doesn't work well. How glaring is it when the cloning uri, which is wide sequence of letters, is squeezed into a narrow sidebar and thus mostly cutoff. It is is awful. Did they consider drop down menus if it was really necessary to reduce the clutter at the top of the page? Otherwise move the navigation menu to the left and allow the page to fill the screen.
Sorry to be negative. I appreciate work to improve things, some of these changes just aren't. Hope they keep working on it.
I have never understood the reason for putting the commit comments of some random file within it next to the folder name.
It's unnecessary noise and what would be far more useful is how many files and folders that folder actually contained.
To be honest I don't really see the point of putting the comments next to the file name either.
Also, I wish for the love of god that they put the file size there.
Then again my primary use case of github is reading code to learn and having a nosey at how good a coder someone is, so I'm generally looking for the bulk of a program, hence the usefulness of file size and the uselessness of commit comments.
It is, of course, not just some random file -- it's the file that has the most recent commit in that directory.
Or rather, it's the commit message from the most recent commit in that directory (it's not so much about files at all).
I find it quite useful, to see if there have been any recent changes in that directory (and specifically when and what) or if it hasn't been changed in years.
I guess the repo's you look at don't write very good commit messages?
If you find the number of days since last change useful... why wouldn't you also find it useful to know what was changed in that last change? That's what the commit message tells you, right?
(and the commit message is also the place you click on in the github ui to see the full commit with diff etc)
The code browser is in my opinion one of the most useful features of github. Commit history and blame combined with the "unnecessary noise" you describes makes it very easy for me to find out the last time I touched some line or file and what changed.
Why do you really care about the file size and amount of files btw?
A lot of files in C# (and I'd imagine Java) just contain interfaces because it's so 'cheap' to make these in IDEs and that's the programming style.
So often you're looking for the files which contain the majority of the code and you're just having to open random files trying to find it. How big the file is shows roughly how many LOC it contains.
This is actually becoming more common in javascript as well as more people unbundle their code, it'd be useful seeing if the file you're about to open is meat or chaff.
I'm fine with showing the last commit time, that is useful information, the comment itself though is invariably noise to everyone but the committer or team.
A few quick first thoughts, having just flipped the switch. I think the description and website fields should be click to edit (and the labels need to be wired up). And I'm not a fan of the increasing emphasis on % LOC by programming language - this seems like an extremely low value metric to be so prominent, and a terrible way to distinguish between repos!
I'm looking forward to digging more into the redesign in my usage of it today. Glad to see GitHub continuing to improve and happy to re-think the current state of the app.
I guess that's a matter of opinion... they're changing things, and whether that qualifies as improvement is, in most cases, likely to end up being pretty subjective (unless the change is exactly limited to something like "our pages now all render twice as fast!").
And really... do we need to make everything about something Jobs said? The only part I'd agree with here is that "foolish" might apply if they drop the ball by making the UI less usable/intuitive, in which case "stay foolish" is horrible advice and will negatively effect a whole lot of users.
It looks like the code viewing area was narrowed. If the redesign was meant to put more focus on content, this decision is perplexing.
I wish they'd make a responsive design that would make use of my 24" monitor. Right now I've resorted to writing a Chrome plugin to widen the code viewing area via CSS.
> It looks like the code viewing area was narrowed.
Doesn't look like it[1].
I'm not sure that a much wider github would be of use to me. Most projects usually place some kind of limitation on the number of characters per line and even in the file browser I don't find filenames long enough to take that kind of space. Maybe you have some other use cases worth sharing?
My team's inherited code (legacy code) where not all lines are trimmed to 80 or even 120 chars. Long file names or deeply nested directories aren't something I run into currently, but I recall running into them on several J2EE apps in the past.
I dislike the right side persistent navigation bar. It takes up considerable room and it makes the page unbalanced as you scroll down. I prefer the content to take up the full width and to be centered. When you scroll down on a long page, the navigation scrolls out of view and content is off center. When I code, I prefer to designate the majority of my screen to the code. The right navigation column seems like wasted space.
This was my first impression too. Especially when viewing the Readme for a project it's much narrower and feels more squashed. They seem to of focused on the project owner use case and ignored the project user use case.
No matter whether you love or hate the new UI, github is going to actively iterate on this design and improve it.
I can't tell you how many times I have had a github tab open and then popped open another and my layout has slightly changed (like shrinking a font or changing colors). They don't stop with UI tweaks until they think things are perfect.
Expect this to continue to evolve even without another major release from them.
I think this redesign is pretty bad for UX but great for design (e.g. it's pretty but useless).
1.) You cannot make a PR from the main repo page anymore, you must go to a branch.
2.) The number of commits is emphasized over the number of pull requests, WTF? This one just blows me away.
3.) The whole PR process itself is largely more complicated and requires many more clicks (e.g. trying to swich repos is a bitch, and you have to click just to see the drop down, which then disappears after you select one).
4.) The right hand navigation bar is more or less worthless and too small.
5.) Moving the link to clone/co to the bottom right of the page is silly and totally makes it harder to find/use. I still don't see how this can be less important than the number of commits...
I still love github, it looks nice, it's just totally unusable. Feels like an April Fool's day joke come early with bad taste.
1. For people visiting their own repositories, the viewing the code itself has little to no value. They more than likely already have it open in their editor / IDE in another window. These folks probably want the issues, PRs and other accompanying features. Collaboration is now the key - not the code itself.
2. For other people (non-committers) looking at a repo, this is different. When I visit other codebases I do actually look at the code to check certain things - what style it is, what frameworks have been used, how complicated the code is, if tests are present etc. Then I check to see what kind of (any how many) issues have been raised.
It might actually make sense to show a different view depending on whether you have commit permissions to the repo or not.
It would be wonderful if you could sort by ctime in the file list view. Bonus points if the the right aligned relative dates could be printed in rfc3339 format. As it is the right aligned relative dates can be disorienting when you scan down the list looking for what has been changed recently.
Tixef.com extends the line to fill the full length of the browser window. If the line is still does not fit, then it is wrapped and icon is inserted to indicate the fact. If you have an office then you probably also own a large monitor if not several of. There is really no sense of keeping fixed layouts nowadays in a product targeted towards professionals.
[disclaimer: Tixef is my project so I may be a bit over the top about it]
To provide review tools you need the code as well as its full history. An API is not going to cut it.
However Git being the beautiful distributed system as it is, you don't have to move your hosting. In fact you can push to multiple Git remotes, or use one for backup, or just for reviews.
You can also push to multiple remotes at the same time by adding two urls for the origin. So if you like the idea of your source files residing on a particular provider then you can keep it there as well.
Heroku works in a similar way, you may store your repo elsewhere but deploys happen when you push to their remote.
The true API here is Git itself not some silly and constantly changing REST protocol over something as stable the Git Object Model.
Their fixed layout is a major cause of that in my opinion. Most developers don't code on old VGA terminals anymore and produce more than 80 characters per line, at times much more.
A layout that provides less space than your average text editor or IDE will lead to unnecessary line breaks.
Actually I was referring to something else: the iPhone-style sideways scrolling animation when you click on a source file name or go back to a directory listing.
There doesn't seem to be a way to opt out. I can't create a pull request from dev to master any more, it shows me the compare page but only gives me to a link to an existing pull request to dev. Merging on the command line it is, then. =/
I'll reserve judgement until I use it but it does look promising.
Now, if they could solve that nasty problem wherein the issues list seems to revert to an earlier revision when you use the browser button I would be a happy camper.
I wonder why the heck they include the Mac OS X app chrome. What's the point? You're wasting a lot of space in the screenshot with useless content. Is it just to show off your mac? It's a website for god's sake, it looks essentially the same in any operating system.
The screenshot has to be contained in something to separate it from the page around it, and window chrome makes it feel a lot more real and less like a mockup. A black border or something wouldn't quite have the same effect.
With many screenshot tools there's a 'capture this window' option, which makes it much more easy to grab the output of a window than choosing 'select a box' and dragging a square over the entire window minus the chrome.
That said, it doesn't look like they did that here...
Not a huge one, but it was nicer to have my most frequent points of interaction at the top. I deal with the code itself in my local repo. I don't need to know how many commits/branches/tags/contributors there are -- that is the redundant info for me, and that should have been shoved to the side.
If I'm using github's UI, it's because I'm managing a project. Might be nice to have a separate "management" interface you can opt into?
tldr: They moved all the "extra" stuff to the side, while keeping the info directly related to the git repo in the center. But the whole point of using github is the value they add, not the core functionality that I can already get through my commandline!