I think the author is trying a bit too hard to shove all the information they can in that space. While it would be nice to have a slightly more detailed overview, I think he may have gone a bit too far…
The only point in the whole article I agree with is that the latest commit per-file isn't particularly helpful. Otherwise I think the changes the author proposes make for a usability downgrade. A cluttered, aimless pile of shipwrecked links and elements floating on the sea of a page.
1. Why are the images cropped so strangely on mobile? It makes this article really hard to read.
2. Shouldn’t the title be “Redesigning the GitHub Repository Page”?
^ And a meta question for programmers, what do you do when English grammar calls for a question mark to be inside your quotation mark at the end of a sentence, but you’re literally quoting something that should not include the question mark? It’s grammatically wrong, but I’ve taken to moving the question mark outside in the case to avoid ambiguity.
I'd title this "Redesigning GitHub Repository Pages". And I don't put punctuation inside quotes, unless I'm quoting an actual person's speech. I guess that's what I find most natural :/
> And a meta question for programmers, what do you do when English grammar calls for a question mark to be inside your quotation mark at the end of a sentence, but you’re literally quoting something that should not include the question mark? It’s grammatically wrong, but I’ve taken to moving the question mark outside in the case to avoid ambiguity.
If rules and correctness disagree, correctness wins. English is not prescriptive, it's descriptive.
> what do you do when English grammar calls for a question mark to be inside your quotation mark at the end of a sentence, but you’re literally quoting something that should not include the question mark?
AP style (at least, according to the cheatsheets I've found online; I don't have access to the current edition of the full guide) only puts periods and commas inside quotation marks-- question marks, exclamation points, semicolons, and other punctuation only go inside quotation marks if they belong to the quoted matter.
So, that makes "Shouldn’t the title be 'Redesigning the GitHub Repository Page'?" correct, according to them, at least. (This is a matter of style more than a matter of grammar, though.)
> what do you do when English grammar calls for a question mark to be inside your quotation mark at the end of a sentence
English grammar doesn't call for it, not necessarily. It's a matter of style, and different style guides prescribe different methods. There's no "officially correct" way, but to me, the only position that makes sense is to put trailing punctuation outside the quotation marks, except in the case where said punctuation is actually part of the source material. Doing otherwise can change the meaning of the quotation.
Half of this works well; some of the redesign of tabs, the elimination of icons, and similar changes look great.
On the other hand, showing the last commit and change time for each file is useful. Where is that information now? It's in a linear commit list, which is helpful for different purposes ("when was the repo last updated and what's up?") but doesn't serve the original purposes as well ("when was this file updated?"). At the very least, the last-changed date would help.
Shoving statistics over on the right-hand side makes the page much more crowded; expanding the space available for files and commits would work better. Notice how the commit list has messages truncated; 70-to-80-character commit messages ought to fit comfortably there.
Where does the README appear, here? That tends to be the first thing I'm looking for in a new project, and it doesn't look like this redesign took that into account at all.
The new extra-busy tab bar makes it harder to get at the things you use every day: issues and pull requests.
I was half onboard with his reasoning to remove the commit messages. But then I realized, they're only useless if they're bad commit messages. Especially if you're using PRs and using "squash + merge" for all your changes (which should really be the default IMO) the commit messages will be the PR titles and PR number and that's pretty useful. And then the commit time for the file is obviously super important.
What else might be really cool is some kind of indicator of how often the file changes, in addition to the most recent change. Like sometimes if you see a file, maybe it was changed 2 days ago but only because someone renamed a method and that made a one-line change in 50 files. But before that, when was it changed? Does it usually change multiple times a week, or was this the only time it changed in the past month? Even if it was just a rough color gradient or something it would be pretty cool to see at a glance which are the most active directories and files in your repo.
And then the commit time for the file is obviously super important.
What's nice about git is that you also get this propagating to the directories all the way up to the root, so you can quite easily see which areas of the code have been changed recently too. This isn't something normal filesystems have (for performance reasons more than anything --- I imagine if one tried to use git as a filesystem such that each file change was an actual git commit, the root directory node would be hammered with constant updates and an enormous bottleneck) but in the context of a VCS it's amazingly useful.
> What's nice about git is that you also get this propagating to the directories all the way up to the root, so you can quite easily see which areas of the code have been changed recently too.
Exactly! It's easy to see at a glance, for instance, that the code changed recently but the documentation hasn't been updated in a long time. Or that the LICENSE file just got updated a few days ago. Or that a new top-level module got introduced.
I like it. The commits per file don't make sense in the current design, and the tab hierarchy doesn't make sense. I don't like the "flat" redesign though, it was better before.
I'm not sure if I'm for or against flattening the hierarchy, but here are a couple of points:
- Currently, the tabs at the the top level are github-related, and those at the second level are git-related. There is a certain sensibility to this.
- Zenhub, which adds a kanban board powered by github issues, adds a tab at the top level, which makes sense according to the above hierarchy. Of course, a third-party browser extension shouldn't be a primary concern if github thinks about redesigning the page.
Most of the ideas are good, especially the size reduction of the header.
Some thoughts:
1. I like seeing when something in a folder has been modified, and be able to spot easily what folders are active and the ones that have not been touched for years. I agree the last commit message is useless.
2. The file and directory list is currently displayed the same on the main project page and when navigating inside sub-directories. How should the sub-directories be displayed with these modifications?
No. I hate it. Especially the part when you're changing a design just because it's 'dated'. The two-level hierarchy split makes perfect sense for git metadata vs github repo metadata. It might not be sexy, but it makes technical sense.
It works. Millions of people are used to it. There's other things to fix (like code review). Stop fucking around with things for no good reason.
I feel like this is a disproportionately angry response for what amounts to some play with the UI, and I think we should praise the author's willingness to share this publicly instead.
Why would someone post this other than to gather feedback? Yes, this redesign idea upsets me. However, that doesn't make the points I raise (from the point of view of a daily GitHub user! and one that uses it professionally!) any less valid.
> Why would someone post this other than to gather feedback?
A good amount of these unsolicited redesigns are to generate interest in what the designer can offer and provide a sample of work.
Other than posting the HN link the OP goes straight to "If you know someone at Github, send them a link to this article.”, so they probably don't necessarily care for feedback (huge assumption based on my experience with past unsolicited redsigns).
> Yes, this redesign idea upsets me. However, that doesn't make the points I raise (from the point of view of a daily GitHub user! and one that uses it professionally!) any less valid.
Your points are definitely valid. But ironically, like the OP, you end your post on a sour note.
By ending with “Stop fucking around with things for no good reason.”, for what is just a harmless redesign by someone that has little-to-no power to affect GitHub's UX, you painted the rest of your comment as unnecessarily critical. I think this is what the parent comment was addressing.
I can understand the irritability as the web is turned into shit by designers, so things that worked fine is now horrible to use because of unnecessary "redesign". I for sure can't mention a website redesign in recent years that made things better. Internet Archive, Gmail all turned into shit.
So when the few things left, that are not horrible and you depend on, are becoming target for "The Designer Treatment", you become angry.
> The two-level hierarchy split makes perfect sense for git metadata vs github repo metadata.
That would make sense, but they don't actually keep that separation. The "Releases" tab is Github metadata, yet it's right by the Commits and Branches. Also, right next to the "Branch" button (git) there's the "New pull request" button (github).
> If you are a programmer, you might be surprised but other people normally don’t like hierarchies. Nested structures are hard to grasp, remember, navigate, and grouping is very often non-intuitive. Nested tabs are one of the worst UI patterns out there.
GitHub is primarily a development tool, so it should be designed for developers. Hierarchies align very well with development tasks, so it's natural to use them for development tools. That other people don't grasp them is not relevant for GitHub.
Also, the three most common navigation tasks I do are "go to the code", "go to the issues" and "go to the pull requests." Those are also the first three tabs at the top of the hierarchy. I don't think that's an accident; I think the designers at GitHub designed the layout so that the most common tasks are on top and first. In other words, they designed GitHub like a tool, not a normal webpage.
With this redesign, I'm going to constantly have to find the "Issues" and "Pull Requests" tabs among a sea of others. That's not good usability.
I've thought that maybe the markdownified README should be flipped up on top, but even that I think is counter-productive. When I'm working with a GitHub project, I commonly want to load up the page and navigate to some files. If not, it's usually not much scrolling to get down to the README. But READMEs can be quite long (which is a good thing), and it would sometimes be a pain to always scroll past them to get to the files. The better solution for that is a good project page.
I think the two natures of Github as a tool for software development and Github as a social coding site are often at odds. Some ways this could be reconciled:
- greater end user customization of the UI layout
- an option to enter a different UI(contributor UI) for repositories you contribute to/own
- make the contributor UI an enhancement on top of the current UI(perhaps a new darker tab bar)
- related to the above, separating out the discovery part into a separate app
In general, I am in favor of greater customizeability in my professional tools, especially something I use as much as Github. I think one reason we as software developers don’t add a lot of end user customizability to our UIs though, is that it adds a ton of complexity to the UI code. This suggests there is opportunity to explore new UI development paradigms and libraries that have end user customizability as a primary concern, instead of a bolted on after thought. I’m curious if anyone is working on such a project.
The only thing I've ever seen actually work is a desktop environment. I did a proof of concept for the Coast Guard using Ozone [0]. It basically acts like a desktop, where widgets are individual frames that act like windows with cross-communication ability.
But even then, internal configuration of widgets is the same problem as before, just scope-limited...
1) Most GitHub users are more tech-savvy (and often more CSS-savvy) than your average MySpace users, and
2) Most GitHub users put a lot of value in their repo pages,
this actually seems like it wouldn't _inherently_ be the worst idea, assuming the proper precautions were in place versus bad actors. Allowing each org to fully customize their git repo almost encroaches upon (or replaces?) project websites, which already has some overlap with README files (which aren't currently prioritized). Kill two birds with one stone by giving developers what to prioritize on their repos?
There is lots of value for me in the fact that all those project pages look alike. I can easily go to any project and immediately know where to look and click. This is useful for doing technical evaluation of projects. On Myspace the goal was to show individuality and creativity. GitHub is about the code.
Good god no! One of the reasons Facebook won imho is simply because you didn't have to go hunting for core navigation features for every single user's profile page. I do emphatically NOT want that with Github... write a website for your project on ghpages if you want it customized.
Especially when it comes to web applications, I'm starting to dread customization.
Just one example: One of the worst platforms/applications I have ever used is built with Sencha/ExtJS, and it causes a ton of bugs and friction. But hey you can move your windows around and resize them, doesn't that make up for features that don't work?
Most software in the 90s were highly customizable and a joy to use because of that. I don't remember customization adding a lot of complexity to desktop applications (having worked with classic VB6, VB.NET (WPF) and Qt4).
The complexity today comes from the fact that there is much more focus and priority on getting the application to match designers' vision. Its extremely complex to offer the user customization while still ensuring pixel perfect UIs. (Emphasis on complex, its not impossible).
In the 90s, how many updates were there, especially introducing new features?
I guess the problem is, if you introduce a new feature in a web app, it can be hidden by the customized design of users. Or it would just appear at a random place in the UI, forcing the user to re customize around that new feature.
Customization usually doesn't mean radically changing things. Its more about moving UI elements around or changing a List into a Grid etc. A combination of "new" highlight with a "Whats New" popup (extra points for short video intro) usually does the trick.
Yeah, I tend to be not interested in customization, and I believe "general population" UX studies show that most people (not necessarily devs) aren't interested in customization either.
An example of a tool set in a similar space as GH that has prioritized customization are Atlassian Confluence and Jira. How many of us enjoy that software? More than GH?
Customization can't save software that hasn't gotten the UX right in the first place.
I agree with that, JIRA is so monstrously difficult. But this kind of limited configuration might not be so bad. If it's kept selective, some configuration is well-loved by technical users, the vast majority of GitHub's visitors.
I think the default order would be used by anyone who doesn't care to configure it.
In some sub-tab of the User Settings panels, there could be a drag-and-drop sort list (like the one for sorting the "featured repositories" on the profile) to arrange the tabs in a different order, and a button to reset them to default.
Maybe one other setting I would add is "dark mode". The CSS is essentially already written in public Chrome browser extensions to "reskin" GitHub's UI. This is because customizing light/dark modes is gaining in popularity. It's a new macOS trend and in my experience surprisingly common in iOS apps too. Since about 70% developers trend towards dark IDEs, it makes sense to have.
Unlike JIRA, I don't think any of these settings should be at the forefront... you should just have sensible defaults and a way to customize it. GitHub Help articles are well-indexed on Google and anyone who wants to know how to change the color mode or tab order is only going to do it about once, so clicking through menus is a familiar and safer-feeling (as opposed to direct links to private UIs) UX, and it's the same as any other process like adding a SSH key, webhook, or app password.
I do think that GitHub's main user base is increasingly loving their customizability. VS Code and Atom gain a lot of traction for their total customizability and extensibility with plugins. I'm not at all suggesting GitHub go in that direction -- but, GitHub is more of a cloud-based software tool than a website. A little bit of customizability goes a long way with user satisfaction, at least to tech-enthusiastic users.
Just little feature flags would be incredibly handy. For example, default to ignoring whitespace in PR diffs (a feature otherwise only available if you know the URL trick, and can't be saved to user settings like your preferred diff layout).
It's the same amount of customizability as "how many emails do you want to display per page" in Gmail. It's enough personalization to be useful and done officially instead of through hacky, dangerous, frequently-breaking Chrome extensions to work around the things that impede productivity.
That noise is the exact reason why I think the design over the years hasn’t strayed away as captured in the screenshots. One of my favorite parts of using GitHub is that the design is clean and easy to navigate. Throwing twenty widgets on there and cramming everything on top of each other adds clutter and distracts users from being able to visually navigate the page. I can’t speak for everyone, but given the chance, I prefer using GitHub over BitBucket and GitLab because the design is much cleaner and easier to navigate.
I block the requests to google-analytics.com, newrelic.com, and statuspage.io.
I allow the requests to atlassian.com, cloudfront.net, "bytebucket.org", and bitbucket.org.
For comparison GitHub connects to github.com, githubusercontent, githubassets.com, and githubapp.com. I am blocking the githubapp.com requests, though.
And finally sourcehut doesn't make any requests outside of sr.ht
Thanks for the feedback on GitLab’s UI density. We’re working to improve the aesthetics and usability of our system, and feedback from the rest of the community helps us do that. If you have specific feedback, please feel free to share more here.
> When I'm working with a GitHub project, I commonly want to load up the page and navigate to some files. If not, it's usually not much scrolling to get down to the README.
The solution I'm using currently for the git repos hosted on my personal site [0] is to show the projects file tree above the README, but allow it to be collapsed by clicking on the projects root directory. Originally, the project tree was collapsed by default, but the click through rate was quite low, so the expanded view became the default.
> Do you mean that your metrics showed that few people were expanding the tree, so you made it expanded by default?
Correct, after it became expanded by default, the hit rate for project files was dramatically higher, showing that users did care about viewing the files. Perhaps the UI could better indicate that it can be collapsed/expanded, but it could also be that it doesn't match the common UX found on the big sites like GitHub that users have become accustomed with.
Ah, I misunderstood slightly. I thought you were only talking about the click to expand the tree. If the hits to the files increased, then it makes sense to have it expanded by default.
> I thought you were only talking about the click to expand the tree.
That makes sense. It would have been an interesting stat to compare, but the metrics only come from resource requests, as those pages don't run any scripts.
Github is certainly used by developers. But I bet 95%+ of views of repositories’ start pages are made by “consumers” of that code.
At least in my workflow, I visit dozens of those pages every week to, for example, choose between alternative libraries.
My own projects’ index pages are definitely a small percentage of the total. And for those views, I would still prefer this redesign that gives me a quick overview of what’s happening.
Personally, I'm reading the README and/or looking at the contents of files. Plus looking at issues. Very rarely am I looking for the releases tab.
I'm amused that people are using the "I only do this every 6 months so I can't remember where it is" argument. If you only need the functionality every 6 months, perhaps not having it in your face every time you use it might be a good thing ...
Isn't the point that everything should be easy to get to (even if you’ve never been to releases, it should be obvious how to get there) but frequently-accessed things should require less effort?
> Also, the three most common navigation tasks I do are "go to the code", "go to the issues" and "go to the pull requests." (...) With this redesign, I'm going to constantly have to find the "Issues" and "Pull Requests" tabs among a sea of others. That's not good usability.
I agree with this point, but it is one with a very easy fix: make them the first three tabs after "Overview" in the redesign.
I’m a big fan of nested hierarchies. But hierarchies only work when they are logical. And on GitHub they patently aren’t: For instance, I’ve got to search for the Releases tab every single time. Its placement below “Code” makes no sense whatsoever. And even though I know this, I’m still disorientated every time. The same is true for some of the other tabs. I agree with you about the Issues and PR tabs, but I think it’s still a better solution to flatten the hierarchy and simply pull these two tabs to the left, directly after “Code”.
As commenters point out in sibling threads, there is a logic to the hierarchy: the top is GitHub operations and concepts, while the bottom are git concepts. (“Releases” are really just tags.)
Releases aren't just tags, they have files and descriptions, it's a whole new things that Github offer. Tags are available through the branch dropdown (this is where I get them when I need them) and they do have a tabs for it in Release (I do see even more so what the article was talking about with the confusion that hierarchy bring), but when I go to the Release page, it's to get an officially packaged release, nothing else.
>Also, the three most common navigation tasks I do are "go to the code", "go to the issues" and "go to the pull requests."
Well, I don't get any pull requests, so my most common navigation tasks are "go to the code" and "go to the releases" and maybe "go to the issues". Now there's an obvious problem: "go to releases" is in a completely different place than everything else! And since I release only once about 6 months, I always spend a lot of time trying to find the releases tab. That is not good usability. There's no reason for "releases" to be a sub-tab under code, since "releases" also hosts binary artifacts that are not in the repo.
This is a great point. The author completely disregards the fact that this is a tool, and a battle tested one at that. Moreover, GitHub has presumably done a lot of testing and analysis on how people use and navigate their site. The fact that author disregards this fact (or, likely possibility) shows a stark lack of understanding in the product side of design. Don't get me wrong, design and it's principles are important and I appreciate pretty stuff as much as the next user. But use those to inform your new products or features, don't assume that "bad" design is the result of poor design choices, but actually smart product decisions by a team with a good understanding of how users actually use the tool. Maybe I'm giving too much credence to GitHub's product team, but the author gave none so I figured I'd toss a vote of confidence their way.
I like hierarchies as an UI metaphor and I agree with you: github is a development tool. Unfortunately, it seems that the author confused his usual ux work with the one he was proposing for github.
That said, hierarchies are dangerous because they hide stuff. It's clear that github's need reviewing.
I didn't like the body of content above the readme as well, and you got me thinking about the positioning.
I was thinking maybe the "Overview" section of the page could be collapsible. By default, it's expanded, whenever you navigate to the repo from GitHub or direct URL. But since many links to GitHub are appended with "#readme" (for example, some package managers like npm/yarn autofill the package URL to be the GitHub repo + #/readme when generating the manifest files), instead of sending the user halfway down the page with an anchor, it could default to having the toolbar collapsed instead.
I think that would be especially better in mobile.
I always have trouble finding the releases section on a repository. Every single time. I need it rarely enough so that it's not readily in memory, and I usually spend 5-10s just moving mouse around before I notice it.
I also dislike icons in general. Use icons or use text (on a button, ...) but not both, was one of the first rules of thumb I've heard about from a friend, and it makes sense. Especially these days when everything is colorless and bland. I mean if icons in the menu row had all different color, it would at least be a useful navigation aid after a while, but that's not how it's used usually.
I really don't understand this icon-ize everything UX trend. Since when do I hieroglyphics instead of English?
Keep icons small, use brief text, employ information hierarchies. Don't turn everything into a jumbled mess of icons "because they look nice."
Edit: This comment is not directed towards you. It's more my frustration after spending two hours last night trying to understand the abysmal JIRA interface.
The tabs especially looks like a terrible idea. Something that had more than enough space on every screen has now become a huge, long list of options that you have to scan every time to find the one you want.
Removal of icons also plays into that since they were the visual hooks you could use to navigate after a little while of usage.
Then the final redesign, I’m not sure there’s anything to say about it other than that I strongly dislike it. Services like github change their image at their peril, and I just don’t think that is worth it.
The tabs redesign suggestion are actually one of the things I like best here!
I hate the two (it's actually THREE including the top black bar) navbars, I always get confused about where to look to find something or what i'm clicking on, and I've been using GH for years!
Yeah, but if you look at the tabs redesign, they're cheating a little. They are using a very busy repo(which most aren't) so the little numbers next to each tab are acting as a divider. Most repos would be really hard to navigate without some sort of additional separation between the tabs.
I totally agree! Tens of times I tried to move to the branches page only to realise that I'm in some view that doesn't display the secondary navigation, and I need to go to main repo page first
Once you get used to the order that will cease to be an issue quick. Think of how many windows you have open in the taskbar, and yet somehow you know exactly where to go to find the one you need. Once you know the general location it will be automatic.
The usability issue that it solves, however, is genuinely serious:
> let’s say I’m in Wiki and need to see Releases. What should I do? There’s no Releases tab visible, so I must figure out somehow that Releases are part of the Code
> Think of how many windows you have open in the taskbar, and yet somehow you know exactly where to go to find the one you need.
That's not the same thing at all because 1) you have a visual indicator (app icon) to help you find what you need, and 2) you are likely switching between windows (thus reminding yourself of their position) much more often than switching between tabs on GitHub. What you're saying is true for power users, but anyone who doesn't use the UI very consistently will still need to scan the tabs to find what they're looking for, because there is no distinct, visual differentiation between them.
That said, I agree that it solves the usability issue you mentioned, I just don't know if this was the best way to do it.
I agree with the OP on multiple tab bars being problematic. What I think their designs are missing is grouping related tabs on the singular tab bar with dividers or colors.
One thing I hate about modern design, and this is on github etc, is the lack of use of color. Its all monochrome to look "professional" but color coding elements by function in a page can really make navigation so much easier. In the OP, just having blue, green, and yellow underlines with a gap under code / commits / branches, releases / issues / pull requests / projects, and wiki / insights / settings tabs would make visual navigation so much easier.
You could then border the file and commit list with blue and the statistics with yellow. The parts of the page related to each "topical heading" could be highlighted with color.
Definitely states the right problems, but not the right solutions.
The commits box is also bigger than the files box, which doesn't make much sense. Whether a commit box even should be there is a big question. How useful is commits to the average developer browsing a repo? I think a bit useful, but not useful enough to have 1/3 of the screen width.
Stats of a repo is pretty nice, because it gives an overview of how active it is, etc. But the problem is that majority of GitHub repos are empty and not that active, so it'll make most of the repos look like ghost towns. Not something you'd want on your site.
Moving all git tabs into the GitHub tabs makes it even harder to use the UI. You have to spend way too much mental load just to find the right tab to click on. It looks better, but will be harder to use.
The "Watch" button, moving description and tags is an improvement, and I'm for a redesign of some sort.
I think it's strange to focus on all these details without addressing what seems to me the overwhelming problem with the GitHub layout - the deprioritisation of the readme. Why is it below the fold?
I was very confused for a considerable time when people would point me to GitHub for a description of a project, because there didn't appear to be a description, just a repo. Was I supposed to build it to see what it was?
This seems very silly in retrospect, but there really was a month or two where I just didn't understand at all what I was supposed to be doing there, and I've never forgotten it.
And why? Why is it so critical that the first thing people see is the file structure, and not a description of the project? Echoing the article, I suppose it makes it "about git", but even when I'm interested enough to start poking around, I'm more likely to clone a project than browse through it on the site.
I mention this in a sibling comment, as I've thought something similar: maybe the README should be on top. The problem, as I mention there, is that when you use GitHub as a tool, it's more common to navigate to the files than refer to the README. And with long READMEs, that's potentially a lot of scrolling to get to the files.
What this implies is that GitHub is not your project page. The README there should be more development focused, and there should be a separate project page which goes into more detail about project-level things.
I missed your comment, it's better reasoned than mine and I think I agree with it.
I was just saying on another comment that I think the problem is GitHub, while maybe it shouldn't be, is the de facto project page for many projects, and is a major use-case.
There perhaps can't be a good solution - it's convenient enough that most small developers can't be bothered maintaining two different information sources about their work, and GitHub certainly has no reason to dissuade people from using it that way, but to prioritise the readme would make actually using the site harder.
Just one of those awkward things you live with, perhaps.
As a developer, the README is useless, I am usually on a Github repo to start looking at code, and I don't want to have to first scroll through a README.
IMHO documentation websites and the like is where people should get their first feeling for a project, that is where the README should be.
That seems like a great idea in principle, but for most small projects the GitHub page /is/ the documentation. If that weren't the case, you wouldn't see half a dozen links to GitHub pages to show off projects on HN each day.
It's all very well to talk about ideals, but you can't ignore reality in the process.
You're right, though, that you shouldn't have to scroll past it every time. I don't really know what the solution is, but having it there but going undiscovered is the worst of both worlds.
If you've read one README on Github, you know to scroll down to see it on every other project. I would argue that it's not a steep learning curve, and it's not like the hide the scrollbar... we scroll in other websites without issue when we are looking for content, especially with ads being most of the content above the fold these days.
Hilariously I feel the exact opposite. I'll use OctoTree if I want to view the code, as github's code view is absolutely horrendous. It's like when your using Mac's Finder, it doesn't make any sense.
I visit the main page of a repo to see the Readme or to go straight to the issues/prs page. I'll use OctoTree to view code.
I see what you're saying, but I think there are two major use cases for Github, one where the README should be first, and one where it should be last. The first is yours, visiting a repo, which often serves as de facto homepage for a project. The second though, is for projects you contribute to or use frequently, where finding out what's new or navigating to particular piece of code is the most important task. I'm not sure what a good way of distinguishing between the two would be.
> I'm not sure what a good way of distinguishing between the two would be.
GitHub Pages makes it easy to create a separate website for the first use case, which you can link to on the very top in the description. Then the README can contain info aimed at (new) developers of the project, build instructions and the likes, which you likely don't have to go to frequently (your 2nd case).
I had the same exact reaction as you when I first used Github. So I think Github's response to this problem is the whole Github.io domain. Those are supposed to be the project landing pages for the plebs while github.com domains are for developers.
It'd rather have it all in one place, with the landing page being the README, and the more developer focused info hidden in tabs, but that's not the current design unfortunately.
I've found a way to author project descriptions under the current layout using Org-mode. The trick is to leverage two features. One is that Github projects will use README.org files as a README file. For instance this is one of mine
The rest of the magic is in the HTML configuration at the top of the file - particularly: #+EXPORT_FILE_NAME: index.html
So then when you export the document to HTML it turns into your Github.io root file. This way you can keep your dev-facing README and public facing Github.io page the same. It's a little ugly.. but it gets out of the way and works
> If you feel disoriented, give it a minute. Once you are used to it, you might notice it’s actually easier on the eyes and a bit lighter.
I've been staring at it for 5 minutes now and I'm still disoriented. The borders and gradients gave the design an attractive depth and by removing them you ruined for me. The whole high-contrast/no-gradient thing is also one of the reasons I dislike using Gitlab. It was all going pretty well before then, though.
I too was sold on all the rest except that last part. Then I read his msg about giving it a chance, and like you tried very hard to immerse myself in it to overcome any possible aversion to change, but no success, that last panel sucks; at minimum the division lines are needed. The rest I love and would like github to implement.
yah, that last step of updating the design (arbitrarily) was where it took a wrong turn. the only other tweak i disliked was removing the last change date on the files, as that's often useful. the rationale and changes for the other items seemed worth consideration though.
Agreed. I was on-board with most of the changes, but that one removed all visual distinction between elements. It became a load of black text on top of a white background with no separation between semantically different elements.
On a related note, Gmail's latest redesign for Android made the exact same blunder when viewed in the compact density. Just sender/subject/sender/subject with very little indication of each one being a separate email. They spent an extra line break, rather than adding a nice horizontal divider, which would have used less space and given more visual separation.
Lack of visual distinction is a general problem with the current design trends. Even Apple suffers from it at times—in Xcode, it's impossible to tell whether certain elements are interactive (buttons vs passive status indicators) without clicking on them.
The thing that drives me up the wall is when text inputs are not made obvious. Google in particular is notorious for not giving any indication that something is a text box, as opposed to just static text. I can't count the number of times I have tried to focus and type into something that I thought was a text field, only to discover that nothing was happening.
Thanks for the feedback on GitLab’s design patterns. We’re working to update our design system, so feedback like this is helpful, and we’ll take it into consideration as we make updates. If you have additional feedback, please feel free to share it here or in a GitLab issue.
It was heading in the right direction for a while, but at the end it basically turned into Bitbucket. With all due respect to the author, I think the current Github UI works just fine, and the fact that it has become the dominant player in the market with a clean interface that hasn't changed much over the years, is a testament to how well it works. I rarely say this, but let's not try to fix this.
Thanks for the feedback on the density of GitLab’s UI. Agree that there is a balance to strike between providing enough information and maintaining scannability and ease of use. If you have specific feedback, please feel free to share it here or in a GitLab issue. We value feedback from the rest of the community.
I loved this whole post until just at the end where he removed the borders around the various sections and it looked like a jumbled mess, for no reason. Didn't stick the landing there.
Agree of disagree with OP's design, you have to admit that his breakdown is very clear and highlights problems well.
Even without adopting his solution, this really gives github some ideas on problem areas to focus on. I would consider hiring this person if I were them.
This is exactly the kind of change that should not get someone hired: a lot of the UX concerns he highlighted are valid, but the net result of his work looked like "complete redesign" to most folks and hides some pretty important information in the process.
The amazing designers that you really do want to find are the ones that will give you the smallest set of improvements that fix UX issues without changing the visual language of the product. If done right, most people wouldn't even notice that the site had changed at all but their daily frustration with being able to find things would decrease.
For example, the nested tab mess can be a real annoyance. It's worse on mobile, too, but the designer managed to tweak the design and completely forget about anything other than desktop dimensions. This is not really forgivable in 2018. The least possible change might be: let's try placing all the tabs together on the screen so that people don't go looking in one list for an item that's in the other. Then, making all the pages have the same navigation group containing both sets of tabs makes sense. At this point, stop!
Certainly, if the company thinks a design looks "dated", it could be updated at some other time, but ideally there would be zero change in information architecture to go along with it. Again, most people wouldn't notice the colors had changed subtly and information would be in exactly the same place it was, but ideally you'd be able to measure things like "number of users reporting that the site gives them eyestrain decreased by XX%".
GitHub certainly isn't perfect, but their UX people do seem to be fairly good. I've been using the product since it looked as it did back in 2013, and without side by side images, I actually couldn't point to any one point in time and say "that's when they redesigned the product and everything changed!".
314 comments
[ 3.6 ms ] story [ 266 ms ] thread1. Why are the images cropped so strangely on mobile? It makes this article really hard to read.
2. Shouldn’t the title be “Redesigning the GitHub Repository Page”?
^ And a meta question for programmers, what do you do when English grammar calls for a question mark to be inside your quotation mark at the end of a sentence, but you’re literally quoting something that should not include the question mark? It’s grammatically wrong, but I’ve taken to moving the question mark outside in the case to avoid ambiguity.
If rules and correctness disagree, correctness wins. English is not prescriptive, it's descriptive.
AP style (at least, according to the cheatsheets I've found online; I don't have access to the current edition of the full guide) only puts periods and commas inside quotation marks-- question marks, exclamation points, semicolons, and other punctuation only go inside quotation marks if they belong to the quoted matter.
So, that makes "Shouldn’t the title be 'Redesigning the GitHub Repository Page'?" correct, according to them, at least. (This is a matter of style more than a matter of grammar, though.)
“Redesigning the Github Repository Page” shouldn’t the title be?
English grammar doesn't call for it, not necessarily. It's a matter of style, and different style guides prescribe different methods. There's no "officially correct" way, but to me, the only position that makes sense is to put trailing punctuation outside the quotation marks, except in the case where said punctuation is actually part of the source material. Doing otherwise can change the meaning of the quotation.
The main thing you want to see with the repo page is the code and the readme, i don't want to see all these commit messages or stats. Irrelevant.
This actually made me appreciate Github's current design :)
On the other hand, showing the last commit and change time for each file is useful. Where is that information now? It's in a linear commit list, which is helpful for different purposes ("when was the repo last updated and what's up?") but doesn't serve the original purposes as well ("when was this file updated?"). At the very least, the last-changed date would help.
Shoving statistics over on the right-hand side makes the page much more crowded; expanding the space available for files and commits would work better. Notice how the commit list has messages truncated; 70-to-80-character commit messages ought to fit comfortably there.
Where does the README appear, here? That tends to be the first thing I'm looking for in a new project, and it doesn't look like this redesign took that into account at all.
The new extra-busy tab bar makes it harder to get at the things you use every day: issues and pull requests.
What else might be really cool is some kind of indicator of how often the file changes, in addition to the most recent change. Like sometimes if you see a file, maybe it was changed 2 days ago but only because someone renamed a method and that made a one-line change in 50 files. But before that, when was it changed? Does it usually change multiple times a week, or was this the only time it changed in the past month? Even if it was just a rough color gradient or something it would be pretty cool to see at a glance which are the most active directories and files in your repo.
What's nice about git is that you also get this propagating to the directories all the way up to the root, so you can quite easily see which areas of the code have been changed recently too. This isn't something normal filesystems have (for performance reasons more than anything --- I imagine if one tried to use git as a filesystem such that each file change was an actual git commit, the root directory node would be hammered with constant updates and an enormous bottleneck) but in the context of a VCS it's amazingly useful.
Exactly! It's easy to see at a glance, for instance, that the code changed recently but the documentation hasn't been updated in a long time. Or that the LICENSE file just got updated a few days ago. Or that a new top-level module got introduced.
I tend to use either "rebase" or "merge" for everything, and I expect people submitting PRs to make good commits.
> What else might be really cool is some kind of indicator of how often the file changes
That's a good idea! How about a sparkline-sized indicator of change activity over time? https://en.wikipedia.org/wiki/Sparkline
I think adding the readme to above the commits/stats would be a good idea. Perhaps make it ~500px and expandable.
- Currently, the tabs at the the top level are github-related, and those at the second level are git-related. There is a certain sensibility to this.
- Zenhub, which adds a kanban board powered by github issues, adds a tab at the top level, which makes sense according to the above hierarchy. Of course, a third-party browser extension shouldn't be a primary concern if github thinks about redesigning the page.
Some thoughts:
1. I like seeing when something in a folder has been modified, and be able to spot easily what folders are active and the ones that have not been touched for years. I agree the last commit message is useless.
2. The file and directory list is currently displayed the same on the main project page and when navigating inside sub-directories. How should the sub-directories be displayed with these modifications?
It works. Millions of people are used to it. There's other things to fix (like code review). Stop fucking around with things for no good reason.
A good amount of these unsolicited redesigns are to generate interest in what the designer can offer and provide a sample of work.
Other than posting the HN link the OP goes straight to "If you know someone at Github, send them a link to this article.”, so they probably don't necessarily care for feedback (huge assumption based on my experience with past unsolicited redsigns).
> Yes, this redesign idea upsets me. However, that doesn't make the points I raise (from the point of view of a daily GitHub user! and one that uses it professionally!) any less valid.
Your points are definitely valid. But ironically, like the OP, you end your post on a sour note.
By ending with “Stop fucking around with things for no good reason.”, for what is just a harmless redesign by someone that has little-to-no power to affect GitHub's UX, you painted the rest of your comment as unnecessarily critical. I think this is what the parent comment was addressing.
So when the few things left, that are not horrible and you depend on, are becoming target for "The Designer Treatment", you become angry.
That would make sense, but they don't actually keep that separation. The "Releases" tab is Github metadata, yet it's right by the Commits and Branches. Also, right next to the "Branch" button (git) there's the "New pull request" button (github).
GitHub is primarily a development tool, so it should be designed for developers. Hierarchies align very well with development tasks, so it's natural to use them for development tools. That other people don't grasp them is not relevant for GitHub.
Also, the three most common navigation tasks I do are "go to the code", "go to the issues" and "go to the pull requests." Those are also the first three tabs at the top of the hierarchy. I don't think that's an accident; I think the designers at GitHub designed the layout so that the most common tasks are on top and first. In other words, they designed GitHub like a tool, not a normal webpage.
With this redesign, I'm going to constantly have to find the "Issues" and "Pull Requests" tabs among a sea of others. That's not good usability.
I've thought that maybe the markdownified README should be flipped up on top, but even that I think is counter-productive. When I'm working with a GitHub project, I commonly want to load up the page and navigate to some files. If not, it's usually not much scrolling to get down to the README. But READMEs can be quite long (which is a good thing), and it would sometimes be a pain to always scroll past them to get to the files. The better solution for that is a good project page.
- greater end user customization of the UI layout
- an option to enter a different UI(contributor UI) for repositories you contribute to/own
- make the contributor UI an enhancement on top of the current UI(perhaps a new darker tab bar)
- related to the above, separating out the discovery part into a separate app
In general, I am in favor of greater customizeability in my professional tools, especially something I use as much as Github. I think one reason we as software developers don’t add a lot of end user customizability to our UIs though, is that it adds a ton of complexity to the UI code. This suggests there is opportunity to explore new UI development paradigms and libraries that have end user customizability as a primary concern, instead of a bolted on after thought. I’m curious if anyone is working on such a project.
But even then, internal configuration of widgets is the same problem as before, just scope-limited...
[0] https://github.com/ozoneplatform/owf-framework/wiki
1) Most GitHub users are more tech-savvy (and often more CSS-savvy) than your average MySpace users, and 2) Most GitHub users put a lot of value in their repo pages,
this actually seems like it wouldn't _inherently_ be the worst idea, assuming the proper precautions were in place versus bad actors. Allowing each org to fully customize their git repo almost encroaches upon (or replaces?) project websites, which already has some overlap with README files (which aren't currently prioritized). Kill two birds with one stone by giving developers what to prioritize on their repos?
I think you underestimate how many "Single commit, push and forget" test repositories are out there.
Just one example: One of the worst platforms/applications I have ever used is built with Sencha/ExtJS, and it causes a ton of bugs and friction. But hey you can move your windows around and resize them, doesn't that make up for features that don't work?
The complexity today comes from the fact that there is much more focus and priority on getting the application to match designers' vision. Its extremely complex to offer the user customization while still ensuring pixel perfect UIs. (Emphasis on complex, its not impossible).
I guess the problem is, if you introduce a new feature in a web app, it can be hidden by the customized design of users. Or it would just appear at a random place in the UI, forcing the user to re customize around that new feature.
Customization usually doesn't mean radically changing things. Its more about moving UI elements around or changing a List into a Grid etc. A combination of "new" highlight with a "Whats New" popup (extra points for short video intro) usually does the trick.
An example of a tool set in a similar space as GH that has prioritized customization are Atlassian Confluence and Jira. How many of us enjoy that software? More than GH?
Customization can't save software that hasn't gotten the UX right in the first place.
I think the default order would be used by anyone who doesn't care to configure it.
In some sub-tab of the User Settings panels, there could be a drag-and-drop sort list (like the one for sorting the "featured repositories" on the profile) to arrange the tabs in a different order, and a button to reset them to default.
Maybe one other setting I would add is "dark mode". The CSS is essentially already written in public Chrome browser extensions to "reskin" GitHub's UI. This is because customizing light/dark modes is gaining in popularity. It's a new macOS trend and in my experience surprisingly common in iOS apps too. Since about 70% developers trend towards dark IDEs, it makes sense to have.
Unlike JIRA, I don't think any of these settings should be at the forefront... you should just have sensible defaults and a way to customize it. GitHub Help articles are well-indexed on Google and anyone who wants to know how to change the color mode or tab order is only going to do it about once, so clicking through menus is a familiar and safer-feeling (as opposed to direct links to private UIs) UX, and it's the same as any other process like adding a SSH key, webhook, or app password.
I do think that GitHub's main user base is increasingly loving their customizability. VS Code and Atom gain a lot of traction for their total customizability and extensibility with plugins. I'm not at all suggesting GitHub go in that direction -- but, GitHub is more of a cloud-based software tool than a website. A little bit of customizability goes a long way with user satisfaction, at least to tech-enthusiastic users.
Just little feature flags would be incredibly handy. For example, default to ignoring whitespace in PR diffs (a feature otherwise only available if you know the URL trick, and can't be saved to user settings like your preferred diff layout).
It's the same amount of customizability as "how many emails do you want to display per page" in Gmail. It's enough personalization to be useful and done officially instead of through hacky, dangerous, frequently-breaking Chrome extensions to work around the things that impede productivity.
Your point over how hierarchy helps programmers use GitHub feels lost on the designer. It feels as if they're designing for a different user.
The other big reason is that Bitbucket loads bunch of trackers and JavaScript from remote servers.
I allow the requests to atlassian.com, cloudfront.net, "bytebucket.org", and bitbucket.org.
For comparison GitHub connects to github.com, githubusercontent, githubassets.com, and githubapp.com. I am blocking the githubapp.com requests, though.
And finally sourcehut doesn't make any requests outside of sr.ht
The solution I'm using currently for the git repos hosted on my personal site [0] is to show the projects file tree above the README, but allow it to be collapsed by clicking on the projects root directory. Originally, the project tree was collapsed by default, but the click through rate was quite low, so the expanded view became the default.
[0] https://octobanana.com/software/fltrdr
I would interpret the data as meaning that most people don’t care about the list of files, so it’s better for them to be hidden by default.
Correct, after it became expanded by default, the hit rate for project files was dramatically higher, showing that users did care about viewing the files. Perhaps the UI could better indicate that it can be collapsed/expanded, but it could also be that it doesn't match the common UX found on the big sites like GitHub that users have become accustomed with.
That makes sense. It would have been an interesting stat to compare, but the metrics only come from resource requests, as those pages don't run any scripts.
At least in my workflow, I visit dozens of those pages every week to, for example, choose between alternative libraries.
My own projects’ index pages are definitely a small percentage of the total. And for those views, I would still prefer this redesign that gives me a quick overview of what’s happening.
Personally, I'm reading the README and/or looking at the contents of files. Plus looking at issues. Very rarely am I looking for the releases tab.
I'm amused that people are using the "I only do this every 6 months so I can't remember where it is" argument. If you only need the functionality every 6 months, perhaps not having it in your face every time you use it might be a good thing ...
I agree with this point, but it is one with a very easy fix: make them the first three tabs after "Overview" in the redesign.
Well, I don't get any pull requests, so my most common navigation tasks are "go to the code" and "go to the releases" and maybe "go to the issues". Now there's an obvious problem: "go to releases" is in a completely different place than everything else! And since I release only once about 6 months, I always spend a lot of time trying to find the releases tab. That is not good usability. There's no reason for "releases" to be a sub-tab under code, since "releases" also hosts binary artifacts that are not in the repo.
That said, hierarchies are dangerous because they hide stuff. It's clear that github's need reviewing.
I was thinking maybe the "Overview" section of the page could be collapsible. By default, it's expanded, whenever you navigate to the repo from GitHub or direct URL. But since many links to GitHub are appended with "#readme" (for example, some package managers like npm/yarn autofill the package URL to be the GitHub repo + #/readme when generating the manifest files), instead of sending the user halfway down the page with an anchor, it could default to having the toolbar collapsed instead.
I think that would be especially better in mobile.
I also dislike icons in general. Use icons or use text (on a button, ...) but not both, was one of the first rules of thumb I've heard about from a friend, and it makes sense. Especially these days when everything is colorless and bland. I mean if icons in the menu row had all different color, it would at least be a useful navigation aid after a while, but that's not how it's used usually.
Keep icons small, use brief text, employ information hierarchies. Don't turn everything into a jumbled mess of icons "because they look nice."
Edit: This comment is not directed towards you. It's more my frustration after spending two hours last night trying to understand the abysmal JIRA interface.
Removal of icons also plays into that since they were the visual hooks you could use to navigate after a little while of usage.
Then the final redesign, I’m not sure there’s anything to say about it other than that I strongly dislike it. Services like github change their image at their peril, and I just don’t think that is worth it.
I hate the two (it's actually THREE including the top black bar) navbars, I always get confused about where to look to find something or what i'm clicking on, and I've been using GH for years!
The usability issue that it solves, however, is genuinely serious:
> let’s say I’m in Wiki and need to see Releases. What should I do? There’s no Releases tab visible, so I must figure out somehow that Releases are part of the Code
That's not the same thing at all because 1) you have a visual indicator (app icon) to help you find what you need, and 2) you are likely switching between windows (thus reminding yourself of their position) much more often than switching between tabs on GitHub. What you're saying is true for power users, but anyone who doesn't use the UI very consistently will still need to scan the tabs to find what they're looking for, because there is no distinct, visual differentiation between them.
That said, I agree that it solves the usability issue you mentioned, I just don't know if this was the best way to do it.
One thing I hate about modern design, and this is on github etc, is the lack of use of color. Its all monochrome to look "professional" but color coding elements by function in a page can really make navigation so much easier. In the OP, just having blue, green, and yellow underlines with a gap under code / commits / branches, releases / issues / pull requests / projects, and wiki / insights / settings tabs would make visual navigation so much easier.
You could then border the file and commit list with blue and the statistics with yellow. The parts of the page related to each "topical heading" could be highlighted with color.
The commits box is also bigger than the files box, which doesn't make much sense. Whether a commit box even should be there is a big question. How useful is commits to the average developer browsing a repo? I think a bit useful, but not useful enough to have 1/3 of the screen width.
Stats of a repo is pretty nice, because it gives an overview of how active it is, etc. But the problem is that majority of GitHub repos are empty and not that active, so it'll make most of the repos look like ghost towns. Not something you'd want on your site.
Moving all git tabs into the GitHub tabs makes it even harder to use the UI. You have to spend way too much mental load just to find the right tab to click on. It looks better, but will be harder to use.
The "Watch" button, moving description and tags is an improvement, and I'm for a redesign of some sort.
I was very confused for a considerable time when people would point me to GitHub for a description of a project, because there didn't appear to be a description, just a repo. Was I supposed to build it to see what it was?
This seems very silly in retrospect, but there really was a month or two where I just didn't understand at all what I was supposed to be doing there, and I've never forgotten it.
And why? Why is it so critical that the first thing people see is the file structure, and not a description of the project? Echoing the article, I suppose it makes it "about git", but even when I'm interested enough to start poking around, I'm more likely to clone a project than browse through it on the site.
It just feels intentionally obtuse.
What this implies is that GitHub is not your project page. The README there should be more development focused, and there should be a separate project page which goes into more detail about project-level things.
I was just saying on another comment that I think the problem is GitHub, while maybe it shouldn't be, is the de facto project page for many projects, and is a major use-case.
There perhaps can't be a good solution - it's convenient enough that most small developers can't be bothered maintaining two different information sources about their work, and GitHub certainly has no reason to dissuade people from using it that way, but to prioritise the readme would make actually using the site harder.
Just one of those awkward things you live with, perhaps.
IMHO documentation websites and the like is where people should get their first feeling for a project, that is where the README should be.
It's all very well to talk about ideals, but you can't ignore reality in the process.
You're right, though, that you shouldn't have to scroll past it every time. I don't really know what the solution is, but having it there but going undiscovered is the worst of both worlds.
I visit the main page of a repo to see the Readme or to go straight to the issues/prs page. I'll use OctoTree to view code.
GitHub Pages makes it easy to create a separate website for the first use case, which you can link to on the very top in the description. Then the README can contain info aimed at (new) developers of the project, build instructions and the likes, which you likely don't have to go to frequently (your 2nd case).
Quite useful when you want to point people directly at the description.
It'd rather have it all in one place, with the landing page being the README, and the more developer focused info hidden in tabs, but that's not the current design unfortunately.
I've found a way to author project descriptions under the current layout using Org-mode. The trick is to leverage two features. One is that Github projects will use README.org files as a README file. For instance this is one of mine
https://raw.githubusercontent.com/geokon-gh/linearsystems-pa...
it shows up in the README spot https://github.com/geokon-gh/linearsystems-part2 and also in the Github.io https://geokon-gh.github.io/linearsystems-part2/
The rest of the magic is in the HTML configuration at the top of the file - particularly: #+EXPORT_FILE_NAME: index.html
So then when you export the document to HTML it turns into your Github.io root file. This way you can keep your dev-facing README and public facing Github.io page the same. It's a little ugly.. but it gets out of the way and works
I've been staring at it for 5 minutes now and I'm still disoriented. The borders and gradients gave the design an attractive depth and by removing them you ruined for me. The whole high-contrast/no-gradient thing is also one of the reasons I dislike using Gitlab. It was all going pretty well before then, though.
On a related note, Gmail's latest redesign for Android made the exact same blunder when viewed in the compact density. Just sender/subject/sender/subject with very little indication of each one being a separate email. They spent an extra line break, rather than adding a nice horizontal divider, which would have used less space and given more visual separation.
The thing that drives me up the wall is when text inputs are not made obvious. Google in particular is notorious for not giving any indication that something is a text box, as opposed to just static text. I can't count the number of times I have tried to focus and type into something that I thought was a text field, only to discover that nothing was happening.
That's precisely a front where GH wins (over Gitlab): it's visually calm and sparse, ideal for something that would be part of daily, thoughtful work.
Even without adopting his solution, this really gives github some ideas on problem areas to focus on. I would consider hiring this person if I were them.
The amazing designers that you really do want to find are the ones that will give you the smallest set of improvements that fix UX issues without changing the visual language of the product. If done right, most people wouldn't even notice that the site had changed at all but their daily frustration with being able to find things would decrease.
For example, the nested tab mess can be a real annoyance. It's worse on mobile, too, but the designer managed to tweak the design and completely forget about anything other than desktop dimensions. This is not really forgivable in 2018. The least possible change might be: let's try placing all the tabs together on the screen so that people don't go looking in one list for an item that's in the other. Then, making all the pages have the same navigation group containing both sets of tabs makes sense. At this point, stop!
Certainly, if the company thinks a design looks "dated", it could be updated at some other time, but ideally there would be zero change in information architecture to go along with it. Again, most people wouldn't notice the colors had changed subtly and information would be in exactly the same place it was, but ideally you'd be able to measure things like "number of users reporting that the site gives them eyestrain decreased by XX%".
GitHub certainly isn't perfect, but their UX people do seem to be fairly good. I've been using the product since it looked as it did back in 2013, and without side by side images, I actually couldn't point to any one point in time and say "that's when they redesigned the product and everything changed!".