Hacker News new | past | comments | ask | show | jobs | submit login
Redesigning GitHub Repository Page (tonsky.me)
614 points by kirushik 56 days ago | hide | past | web | favorite | 303 comments



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


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.


Yes that is indeed a problem, but not unsolvable.

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.


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

[0] https://github.com/ozoneplatform/owf-framework/wiki


GitHub should go full MySpace, completely custom css per project.


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.


Considering:

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.


3) Most developers are absolutely awful graphic designers.


> 2) Most GitHub users put a lot of value in their repo pages,

I think you underestimate how many "Single commit, push and forget" test repositories are out there.


Isn't this github.io ?


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.


I agree, but that's another point: maybe hierarchies could just be "refactored", e.g. letting Releases be a top tab item


> 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 think the author describes the problem with the redesign the best: its noisy.

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.


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.


Strongly agree with this, and it's probably the biggest reason I don't use BitBucket unless I'm getting paid to.

The other big reason is that Bitbucket loads bunch of trackers and JavaScript from remote servers.


Names/urls of the trackers and scripts?


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.


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.


However, a lions share of the revenue for github will be from developers, rather than "consumers".


The point was that developers themselves are often browsing repositories they do not own/contribute to.


And what is it those developers are doing?

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?


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.


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

[0] https://octobanana.com/software/fltrdr


Do you mean that your metrics showed that few people were expanding the tree, so you made it expanded by default?

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.


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


Is the front end itself available?


It's all server-side rendered. I've been considering open sourcing the site, but there's some cleaning up to be done first.


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.


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


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.


But maybe it’s time to fresh it up a little? Get rid of gradients, dirty washed-out colors, unnecessary separators, add a little more air.

No, no, no, NO!!!11 I've had it with these "sea of floating text on an expanse of white" redesigns, seeing yet another one follow this mindless trend just disgusts me thoroughly. The lines, subtle gradients, and other affordances of the old design serve to organise and direct your eyes into the appropriate sections; without them, everything blends together into a jumbled mess and it almost looks like the stylesheet didn't load fully.

If you feel disoriented, give it a minute.

I've had to put up with such redesigns for literally years now (I don't remember when the trend started --- mid 2010s?) and I don't feel them getting any better --- and eventually get around to making a user stylesheet to make them look better than they used to.

In contrast to the article this is one of the very few redesigns of a site which I actually would like (not mine, previously discussed at https://news.ycombinator.com/item?id=17242367): https://pbs.twimg.com/media/De17PIKXUAE27W6.jpg:large

If you know someone at Github, send them a link to this article. Maybe someone there will like my ideas and eventually get to implement them

Hopefully not. "Don't make me get out the custom stylesheet editor..."


Can't tell if the irony is lost that both GitHub UI mocks are by the same designer, Nikita Prokopov.[1][2]

[1] Windows UI satire https://twitter.com/nikitonsky/status/1003593821723267072?s=...

[2] Honest redesign http://tonsky.me/blog/github-redesign/


Can some UI expert chime in what it is about the windows style redesign that makes everything so absolutely clear and easy to find? I can find everything literally at a glance?

It's not sexy, quite the opposite but god does it run electricity through my fingers. I feel like i would use the shit out of it.

Is it association and familiarity with the old windows UI or does it follow human nature better?


It's called nostalgia. It's emotional, not rational.

Ask any 16 year old (like my son), who came of age having no context for what the windows 95 UI even looked like. Shocker, he vastly prefers flat interfaces, ie. like the design of Notion.

The problem I see in this github redesign has nothing to do with the fact that it's flat. It's tougher to use because it's just bad design. The three columns make it insanely dense in terms of information (eliminates any hierarchy) and adds in weird red underlines (which typically mean "error") for no reason. Also the button styles are all inconsistent in the final version.

The first part of the article was great, the second part he started going off the reservation. I think he's strong in terms of a UX thinking but lacks the skills of visual designer who would better implement his thinking visually.


No, it's not nostalgia, goddammit. It's because it contains good visual affordances. Skeumorphism isn't pretty, but it works because our eyes are naturally trained to perceive the visual hints. Our eyes are trained to subconsciously perceive depth via shadows. To perceive clear edges and group things by them.

I really, really hate that 99% of all UX designers are basically graphic designers who are good with visual flourish but without the tiniest bit of interest into half a century worth of HCI research into what makes interfaces visually easy to read. So they end up with whatever graphical look is hip without understanding the usability consequences. That may make a page look good as a whole in the "conforms to current graphic design trends", but it destroys the ability to organize the individual elements.

EDIT: Also, skeuomorphism when done right can be pretty, and if you really want you can still combine it "flat" design by using hints of shadows and depth for better readability - look at games like Snake Bird for examples of that. In general I agree with Bret Victor that the best place to look for good interface design these days is successful computer games, because if it doesn't feel right to play (that is: interact) with, the designers tend to throw it out, and it is the most likely place to see experimental interface design.


Skeumorphism produced good and bad UI designs alike, just like the new flat style. As an example what can work in terms of the newer style is google’s material design.

I am a designer and one of my favourite websites uses the browsers default theme.

Designers can run into the danger of rationalizing changes to fit the visual goal they want to reach instead of the other way around. Form surely should follow function — but it should also follow social convention and usage.

This guy is right that to a non-git person the commit mrssages make no sense. I remember when I started using it and asked myself why the discriptions of the directories are so weird.

Now that I use git I’d rather have them. Our designer here is rather quick in judging it’s usefullnes. These messages describe the state of your remote repository.

I am mostly fine with the proposed menu changes, but again throwing out useful things like the edit button or the fork numbers is not a good idea. This is exactly the class of things you wanna see when you open the main page of a repo and there is not much elsewhere where it would make sense.

If I had to redesign github, I’d first spend a fair time assessing what works and what doesn’t, then reorganize the thing and only in the end decide on how to redesign it. Removing existing functionality is always a thing that should be very well considered.


>I really, really hate that 99% of all UX designers are basically graphic designers who are good with visual flourish but without the tiniest bit of interest into half a century worth of HCI research into what makes interfaces visually easy to read

You probably won't be downvoted because of the audience bias here, but that's like saying "I really hate that 99% of all engineers are basically code monkeys with zero understanding of...[insert thing here]"

It sounds like you've simply worked with bad designers and/or got burned by a bad redesign of a product you use. Sorry. Just know you're throwing the baby out with the bathwater.

First, you seem to be confused about what skeumorphism is. You're arguing about shadows. Skeuomorphism is not about shadows. Skeuomorphism is when you design a digital interface to mimic the old "real world" task it is designed to replace. Like how Apple Books used to have a literal 3d bookshelf as part of the interface.

Moving away from this is not a "trend." It is the natural progression of technology. When more people read words on screens than they do on paper, the bookshelf ceases to be an affordance--it just becomes distracting visual noise.

Shadows play a large role in most modern "flat" interfaces. Material design is just one example. Not sure what your point is here?


I have a master in interaction design and I'm being critical of my own field.

EDIT: Also, no, I did not misunderstand what skeuomorphism is, your own definition of it is what is too limited. Using fake depth and shadows on a design element to give it a 3D look like a real-world button is a form of skeuomorphism, because it relies on an understanding of real-world buttons that can be pushed.


Even if he is wrong about the literal meaning of skeumorphism- he very well pointed out what was right about the windows UI. And I think his intension with the charged statement was to convey the meaning that people talk without knowing what they are talking about.


My intention with discussing the meaning of skeuomorphism is to also convey that people talk without knowing what they are talking about.

Being vaguely angry about "young designers" and their "hip flat interfaces" is a common trigger on HN. I've seen it here countless times, and its rarely insightful. The argument is rooted in a the fallacy that designers only care about making "pretty" things.

Likewise, I've also heard it the same way towards engineers. 99% of engineers only care about cool technical solutions and not meeting users needs. When you've drawn such a broad stroke, it's not a basis for good discussion...just a flamewar.


> Being vaguely angry about "young designers" and their "hip flat interfaces" is a common trigger on HN.

No, the triggering part of your message was the "nostalgia" claim, which isn't supported by the evidence. Even young people typically have an easier time finding their way around interfaces with an older visual design than a modern flat design (all else being equal). This has been tested.

The fact that you claimed it anyway tells me that you have opinions on UI design but don't bother to check if they hold up.


Would you mind pointing to a good resource with a brief write up on the state of the art of good UI, as you pointed in your first comment? I'd also like to read up on the shadow stuff a bit, on how to do it right.


I think he only got the name wrong- he was right about what caused Win UI to "just work" and in general about how the shadow stuff is useful


The Windows 95 "3D" look isn't skeumorphism. Skeumorphism refers to design touches that mimic real life objects. The big example is from early iOS which had things like virtual leather stitching in apps or lined paper in the Notes app or shelves in the iBook app.


As I mentioned elsewhere:

> Using fake depth and shadows on a design element to give it a 3D look like a real-world button is a form of skeuomorphism, because it relies on an understanding of real-world buttons that can be pushed.

Note that these effects are always on objects that have interactive behavior with real-life analogies. Windows for example can be "picked up" and "moved". It casts shadows to mimic the idea of one window being in front of another. The mock-up tabs in the Win95 interface can be clicked on and also mimic real-life tabbed file folders.

Yet at the same time, a table does not feature any drop shadow or fake depth effects. A table cell doesn't have a real-life analogy of an object that can be picked up and moved around. It does feature a visible grid to help eye saccades.

Look up the history of the desktop metaphor. It's based on actual physical desktops. You know, the ones in administration with paper folders which contain files. For most modern people it is skeuomorphism hiding in plain sight.


Thank you for going into detail- I was pretty sure it was UI and you pinpointed what.

Could you point me to some reading on shadow stuff please?


Just to be clear, are you only complaining about the OP's redesign? Or is this aimed even at the current GitHub look?


Not a UI expert professionally but here's what it is:

Windows has standardized and reused GUI elements across every application. So it's immediately clear what's a button, tabs, a subwindow, and how tab hierarchies work (notice they have a bounding box on the tab contents they will change).

Modern web-design disregards all of this because it prioritizes being visually pretty over being easily-recognizable.


I bet the last two aren't mutually exclusive... (i'm not a UI expert either)


This is most probably the result of the UI making you resurface good memories of your past.

Anyway the old Win UI was extremely clear in creating visual hierarchies, when not too many layers were on the screen — modern UI tends to be optimized for a way larger amount of layers, or the opposite, a hyper reduced hierarchy complexity (not the ergonomic / perceived complexity)


Thanks.

I'd love to see a breakdown of what creates this clarity, like how the OP has for every element type.

I know it might seem like an exaggeration but I was physically invigorated by it.


Indeed... if it ain't broke, don't fix it.

http://tonsky.me/blog/github-redesign/210_compare.png


Theres usually some value in design trends, but the OP's github revamp where you can't tell non-interactive text from buttons is painful. The whole point of a button is to indicate interactivity, if your idea of an interactive control is text with maybe a bar under it don't be surprised when users are totally lost.


I thought some of his suggestions were pretty decent. But then he just threw everything away by mucking around in the Code, I mean Overview tab. His last design, without the guiding lines, make it look like jumbled shit pie.


At the time of this posting I got 13 points for expressing a popular opinion. I'm not sure it deserved it. Its not that I disagree with what I wrote, but it could have been more thoughtful. This kind of thing just reinforces my feeling that HN's vote system is broken.


I have the same feeling. He proposed a very good changes and then started to mess up Code…


I wouldn't mind seeing the latest commit history there, but the stats are totally out of place.


Agree; though even before the latest commit history, I’d much prefer the README to be hoisted up there, so it’s at least visible when I first visit a repo.


I haven’t used the gui or windows as primary os for over a decade but that was instantly grokkable, they really nailed the gui in win2k been downhill ever since.


_If you feel disoriented, give it a minute._

The guy spends a very long article explaining how things could be laid out easier to orient yourself in and then asks you to give a minute to get used to his color scheme.


This criticism seems somewhat unfair. I believe they were implying that familiarity with the old design will strongly bias your initial reaction, and giving it just a few more seconds will help to avoid that trap.


No. If the new design is better, I will immediately go "oh wow, that is good". If I have to give it time until my bias goes away, the new design is not necessarily better, merely different.


First half of the article that redesigns the navigation is actually pretty good. It got me hooked and i find it valuable.

When they started touching the content, I got a lot more hesitant.

1. I can't articulate why, but honestly it's extremely useful to see the last commit message on each file. It gives me a sense of which files have changed and if my changes are still the latest ones. It's not foolproof, but it doesn't have to be. It's more psychological but still necessary in a comforting sense.

2. Second, the reason github was successful is because unlike other repository UI's, it showed the code front and center. Nobody wants to look at a commit log, which is the approach that most other repositories used to take. Github cleverly realized that people want to jump right into the code or better yet understand the code, so they showed the file browser and a README. That pattern seems so obvious to us now but it wasn't always. It's kind of laughable that the article focused so much on design but failed to get the core of that idea.


Yeah, I was totally with the author for steps 1-7, but I have problems with the last four steps.

Personally, I think step 9 shows exactly where the author is a bit out of touch. He seems to see GitHub as a sort of code social media site where statistics about the repository are just as valuable as the code itself. In some cases (especially open source), I can see that being kind of true, but I think GitHub gets far more use as a private internal collaboration tool in the work place. In that case, the code itself is far more valuable than anything else and deserves the majority of the screen space.


I think, even as an internal collaboration tool, the faces of who has been touching a repo recently are very valuable. Who do I go to for help, or to get a PR approved, or to request a new feature?


Look at last commit, look up username, email. Where did their face come into it?


I find the commit messages confusing, but find the last changed dates more useful (probably because of overly large mega-commits)


Yeah, that second line of development went in another direction with different guiding principles.

If the first set of changes can get positive reviews here, maybe they'll get merged.

The second line could benefit from some questions about its targets and see how they align/diverge with the aims of a common vcs UI model. I wonder how this matches other UIs.

In any event, a roadmap would help so we could put this in a broader view of where and how it fits in to our needs. See also, https://github.com/isaacs/github/issues/


I agree with the author, the last commit to touch a file or directory isn't very useful. A single white space change will replace the message for a large refactor.

The commit message is a proxy for freshness, but only if you are familiar with the commit log. It is a proxy for related changes, because a commit will update the details for many files.

'Freshness' indicated by color that is more washed out the older the file achieves the first use case. A sparkline showing changes over time would indicate recent changes, hot files, related changes, and freshness.


This really depends on how disciplined your commits are. Yes a refactor makes it useless but really, in my opinion, a whitespace only change should be a seperate commit. Additionally a commit should be a group of changes that make sense together, certainly not two unrelated features. I think this is why I tend to find the last commit a pretty valuable field.


If the whitespace only change comes after the refactor, then the last commit message is "fix whitespace."


> in my opinion, a whitespace only change should be a seperate commit

yeah and now your 'most recent commit' is 'fix whitespace' instead of whatever your relevant commit message is. No matter how disciplined your colleagues are, commit messages describe what was done and sometimes what was done is just cleanup or refactoring.


I don't - I use this quite a lot in the current view to see how active they still are. The commit log is maybe nicer - but as an external user of something hosted on GitHub - that level of detail is actually not that interesting. A "last updated" would be more useful.

If you would get the commit/pull req/issue list in your default view when you have commit rights on - or have been contributing to a repo, sure, seeing the commit/pull req/issue log could be an interesting information stream in that situation.

But then lastly - the other statistics? It just creates an information overload. I prefer a cleaner look with a single focussed view.


It gives me a sense of which files have changed and if my changes are still the latest ones.

Or as I've had to do with other VCS in the past, "what was the last thing that happened to this file?" is a commonly asked question which that description answers, especially when there is a bug in it.


Right. More generally, this UI proposal (as most unsolicited ones are) is a snapshot of a single page. It doesn't aim for consistency across the other pages, or look at workflows involving more than one page.

"What happened to this file?" is one of the most common tasks I have, and it's poorly supported by every web VCS interface I've used, including GitHub. This proposal would make the situation even worse, by hiding any remnant of changes in the file listing.


If I wanted to see the history of a file I would go to that file for more context. I agree with the author that I don't think it's useful enough to show in the front page.

I personally care about the commit log most of the time I go onto github, or the issues, or pull requests. Not that keen on navigating to files from github.


I use the commit / date bit to work out which is the actual code part of a project and which parts are just config / build tools.


Removing the last commit message 'because commit messages are often bad' was one thing, but tossing out the last change date alongside it with nary a mention? Unforgivable.


I feel conflicted. There's a value to show the log graph on project's home. It feels that the main emphasis is not really the static nature of source but the contribution you can make to that tree (as in branches history graph).


> I can't articulate why, but honestly it's extremely useful to see the last commit message on each file.

Pride and curiosity.

If they are your changes, and they are on a big/famous project, it's immensely rewarding to stare at your name in the commit log. Making things a simple chronological list only emphasizes the most recent committers overall. The fact that you're a ninja who improved something that nobody else was willing to is obscured. It satisfies the human "mastery" motivator.

As for curiosity; I'm not going to pretend to be some compiler or JIT guru (although I wish I was). That being said, I can focus on that area of <thing> and see what people have been doing, possibly scraping off something off of that wisdom iceberg.

I have a huge amount of respect for the magical things that designers do in my company (the first video on this page[1] is a short demonstration of their utter and humbling talent). That being said, I've disclosed a pretty big idea to these guys and they're talking about ingesting bulk email into ML to learn user habits and suggest ideas. No, guys! Not only are you missing the point, but you're violating privacy!

We all do it. Developers come up with grandiose designs for shit that nobody needs. Designers come up with ideas that are technically impossible. Sales sell things that don't yet exist. Support will stop at nothing, including breaking everything, to solve one issue. Corp/management will create enough processes and red tape that nothing can get done.

I'd still take this article very seriously as Github. There's certainly things there that I wouldn't use but that design is clean and awesome.

[1]: https://www.k2.com/platform/workflow


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.


> Especially if you're using PRs and using "squash + merge" for all your changes (which should really be the default IMO)

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


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.


bingo.


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


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.


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.


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.


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.


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.


They're also ignoring any sort of internationalisation. In other languages there wouldn't even be room to label all those 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


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.


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.


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


I'm not quite sure what the relationship is, but I the releases tab might just show all git tags.


A GitHub release is tied to a git tag, but it's its own thing.


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.

It just feels intentionally obtuse.


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.


I agree it's not much of a learning curve, but neither is learning which icon represents a commit. This entire discussion is about minor details.


A small "Read the full description"-link to the #readme anchor below the inital short description probably would work wonders here.


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.


Using Github's tool for looking at the code tree is mainly so that I can grab a link and point someone to a line in a file.


You can use the #readme anchor to link directly to the readme, e.g. https://github.com/ruby/ruby#readme

Quite useful when you want to point people directly at the description.


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

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


The redesign looks awful, IMO. Way too busy. Too many tabs at the top.

I rarely care about the contributors or the commits in a github repository. I care zero about the stats. All I want are the files.

The last commit is incredibly important to me, since it lets me see if two files changed at the same time by quickly comparing descriptions.


I don't love the design, but what bothers me more is that I disagree with many of the premises informing the decisions, for example:

  - Github tab icons are purely decorative
  - Because we simplified the whole header, we don’t need that color coding anymore
  - Commits often touch files for completely arbitrary reasons, so the last commit tells you almost nothing
  - Get rid of gradients, dirty washed-out colors, unnecessary separators
Finally, cramming so much into one view makes it harder to navigate, not easier.


This 100%. The icons are _not_ purely decorative, they're important visual anchors. They are consistently relevant and descriptive. They've been around for ages now so even if they weren't straightforward devs have learned them already.

It would be like changing the save button because no one uses floppies anymore.

Last commit on files is one of the first things I look at when scanning a new repo.

Changing the colors is about the only recommendation I could tolerate.


> Github tab icons are purely decorative

I actually agreed with that one. He made a pretty compelling argument. The icons aren't universal, and I have to read the words every time anyway.


I don't know. In his giant image asking if the icon is the commit icon, my first though was "history".

I was actually looking forward for me being hilariously wrong, and GitHub having made funnily incomprehensible icons, and he did not deliver!


I agree they aren't universal, so it's not so useful for first-time users, but once you get to learn them I find they help a lot with scanning and recognition.


> Commits often touch files for completely arbitrary reasons, so the last commit tells you almost nothing

That is mostly true if you are casually browsing a repository you are interested in. It is definitely not true if you are a contributor/owner of the repository.


Overall I like this redesign! Some parts I truly enjoy there:

* single layer navigation: it looks busy, but it would improve my life a lot; I find the current one pretty annoying * showing statistics on the main page: this is very useful information for me when I come to evaluate whether I should use the library in my project

* list of commits: again it helps me to see whether the project is still maintained; if the last commit was 5 years ago the project might still be good, but possibly it doesn't work with the new versions of other libraries; also adding tags there is cool!

* icons added to "find/create/upload file" menu, really good idea!

* watching/not watching button

* language names right on the main page. It's very confusing to have to click on the colour bar to see what languages does the project use

And here are some things I'm not sure about:

* colours are more intensive and I feel that my eyes would get tired more easily; I like the current colour palette

* flattening of buttons looks very iOS-ish and I'm not fan of the trend

* there's no separation between columns, for a moment I thought that users avatars belonged to the files column and I didn't know why some files had user next to them and other didn't.

That's a nice experiment and I'd love to see more ideas like this, to understand the way of thinking behind certain design decisions.

On a side, I find it pretty sad that there's so much negativity in this thread. I know people are used to certain designs and don't like changes, but saying "I hate this" is very strong and I don't understand why anyone would have such strong feelings towards other person's blog post.


I was always angry at people telling they don't like my/his/her new haircut, because I know they are just used to the previous one, and this is the only reason they dislike the new one.

About this redesign: I would welcome it with all my heart. For me, GitHub won on the social side. So let's put the social side in front. I find the current project and profile pages very poor and limited. I would welcome ghuser.io redesign as well.

If I really want to scan the code, I clone the repo and scan the code in my IDE. Or I use a browser extension that displays a folder tree in a toggleable-sidebar on the left.

The current "Files" is only useful to click on the files to get to see their contents. The last commit message for each file is something I look at when I'm bored and want to waste time. I also hate to see very old commit message on very old files like LICENSE.


On a side, I find it pretty sad that there's so much negativity in this thread. I know people are used to certain designs and don't like changes, but saying "I hate this" is very strong and I don't understand why anyone would have such strong feelings towards other person's blog post.

You're not just seeing anger about this redesign; you're seeing the cumulative hatred towards every single UI that was redesigned in this way.

Especially in today's atmosphere of excessive modesty it's far too easy to immerse yourself in a "cloud of positivity" and completely ignore everyone saying DO NOT WANT. The real danger here is someone at GitHub with that attitude may actually do it. People expressing strong negative opinions are doing so for a good reason, perhaps you should listen...


I really like reading and seeing explanations like this. Blog posts like this are a a brilliant way to help design design process.

There are some good ideas, and this article does a fine job of calling out problems, but I also can't help but feel the end result is unpolished looking and would perform very poorly when it comes to usability.

* The end result feels unstructured, like elements were just tossed on the page, due the lack of strong grids either from background colors or implied by layout.

* The left and right alignments of elements is basically non-existant, contributing to a messy feeling.

* The "statistics" category will be entirely useless on small repositories, or personal ones, just taking up a huge amount of space for no reason.

* Removing the icons makes it more difficult to develop "muscle-memory" on websites you use a lot. Icons, even if irrelevant, help us pick the item we want off of the page more quickly.


The final result looks too widget-y/SPA-y, overloaded with information.

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.


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


Not everybody speaks English and localisation is expensive. Icons don't require localising.


oof, the curmudgeon is strong in the comments here and I think some perspective is required.

1) no one is actually implementing these changes; this is just a design exercise from someone who has no connection or influence with Github other than I presume being someone who uses it. My reading of this design work up is that it was just a fun exercise for someone with design skills; design kata if you will.

2) as a programmer who has occasionally tried my hand at a little bit of design; to my mind the design process is somewhere between fricking hard and near impossible and I appreciated the article taking me through his thinking and the incremental changes along the way. I may not like or agree with all of his choices but I really liked the insight into the process.

Obviously it's fine to not like the final design he ended up with, but given the above context I think the level of harrumphing discontent of some comments is not really warranted.


My reading of this design work up is that it was just a fun exercise for someone with design skills; design kata if you will.

Literally applying the bland "no borders, no contrast, white everywhere" trend cookie-cutter style is not what I'd call "design skills". Sadly there are very few actual good designers out there, but their work is easy to identify because they stand out in a good way. This one just looks like another "me too" redesign.


I don't trust github to be that smart.

This is a well upvoted and discussed post on hackernews, if the arguments weren't strongly in opposition, there is a chance somebody at github will be stupid enough to follow this blog. There still is even with all of this pushback.


I make complaints about the small shit that github do with their responsive redesigns and they still don't even fix them.

The responsive nature of the new frontpage is garbage. Because you expect that at least 95 percent of developers using the site are doing so on the desktop. If your browser window is too small, you lose search behind a hamburger button and a navigation menu that only looks like it belongs in your hand, not on your desktop.

We're lucky this only affects the frontpage, and not within any repos were developers are doing actual work


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.


Having "branches" and "Pull Requests" tabs on the same level just doesn't make sense :/

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


This was an interesting take, but personally I think lands with something that misses the mark. I collaborate with my team in slack. I’m really using github to get to my files quickly, view history, or I jump to issues. Any collaboration on github I would say is largely secondary (from my personal experience anyway). Nobody on my teams has ever been waiting on Github for any type of real-time activity, so even PRs review requests are generally communicated through some type of chat.

Personally I feel the author’s final design is also a step backward - while I realize things have been “cleaned up”, a horizontal menu with that many options is too many - and they are not of equal value. The existing division is helpful based on real life use - not the authors idea of what looks good. I don’t need menu items I rarely touch given the same importantance of the ones I use daily - I don’t want to even accidentally read them - it wastes my time. Also, how quickly does this need an alternative solution for narrower screens? Lastly, the authors design is looks to me just like stack overflow - I don’t think it’s fair to say it’s any more modern than githubs current design which has strong and consistent visual language I appreciate as a benchmark for how other products could look and feel. Github looks like GitHub in every part of GitHub, and for me at least, that’s a good thing.


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.


The first several changes, which stick firmly to the principle of “design is how it works”, would help noticeably. The last step, where it starts to try restyling, is no longer “how it works” and that goes too far for me; contrast is lost, things that aren’t too important are suddenly loud and distracting, etc. (i.e. everything I hate about many “modern” web sites).


I like a lot of these suggestions. For instance, it's true that I never get anything out of the commit messages in the file browser (though "how recently has this file been updated?" is often useful).

One other thing I've never understood about the GitHub UI is why the issues search defaults to open issues. I have literally never wanted to restrict my search in that way. Maybe it's just geared towards maintainers? As a user of a project, I would rather land on a closed issue with a solution to the problem I'm seeing.


As a developer/maintainer of projects, the commit messages in the file browser and open issue view are both incredibly useful.

There's important metadata about the structure of a project when looking at the last commit of a group of files: do they all change together? They are more tightly coupled to one another if so. If all the files are touched by each commit, then there's an issue with the project's development process or organization of code. I also tend to run into issues frequently that were introduced by the last change to a particular part of the codebase. If I can navigate to the appropriate directory and look at the commit messages for each file, I can often be pointed directly at the commit that caused the problem and the files involved with the change.

Secondly, when developing, I'm already running the latest version or something later, so looking at closed issues contains no useful information whatsoever. I'm looking for two things: 1) What I should work on next, or 2) Is the problem I'm seeing already reported and has any work already been done on it?

Not showing open issues also has the negative UX that people will look to see if their issue already exists in whatever page they land on, and if they don't see it, create a new one. Therefore, defaulting to closed issues has the potential to raise the number of duplicate issues by some amount. Project maintainers don't like this much.


> Not showing open issues also has the negative UX that people will look to see if their issue already exists in whatever page they land on, and if they don't see it, create a new one.

I think you misunderstand. The parent comment was suggesting showing both open and closed issues in search results, not only closed issues.


If you had read their comment you'll notice it refers to issue searches. not the main browsing page.


So here's what I suggest to the author: go to the "Issues" page for some project, and see the effect of this redesign.

From my perspective: there's now a lot of useless tabs on the top (commits/branches/releases), the repository description will either take extra space OR will disappear and the tabs are going to shift.

- Getting rid of icons: OK

- Moving description over tabs: bad

- Shuffling tabs around: bad

- Different info instead of code details: meh

- Vanity counters: OK

- Changed style/color-scheme: bike-shedding / meh

Opinionated summary: hit and miss.


The vanity counters argument just seemed to me like the author really just doesn’t understand the site or the audience. Which is surprising because he is a dev. The metrics of stars is one thing, that’s a vanity option used by user for bookmarking and project maintainer’s popularity statistic. The fork option has dual functionality, forking the project or viewing all the other forks.

When it comes to Watch, that’s just being pedantic. Maybe non-developers expect to be shown the current state of something, but as a dev I feel that I would like that button to show the inverse, so I know what will happen when I press it. “Click Watch to Watch the repo!”. Two sides of the same coin maybe.


I don't want to be harsh, but most of these are awful ideas and just feel like designing for designs sake and not usability (in fact usability is removed: I like it's easy to edit the file description, file information is actually useful, etc). There's a few areas where github could improve but these are not it. The only thing I agree with is the position of the repo description.

Actual UI things that would improve github imo: - Tree view to the side, so I can browse and preview files to the right (Octotree helps but does not remember position). - Maybe some small custom area before the files, but after the description, for putting things like build buttons, important notes, etc. - Other non-design things (better search, easier way to track conversations, etc)

That's it, nothing else about the current design bothers me.

Also black on yellow! My eyes are bleeding.


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 agree. It's easy to rush to the comments and complain; I had the same initial reaction myself. But I end up agreeing with almost all points made, and wish I could give it a try interactively to give some extra comments -- and I sure hope Github take notice.

---

Some points:

1. That means we can get rid of the [files & folders] descriptions without really losing anything

- I have come to depend a lot on last modified dates for files as an indicator of both a repo's activity level, and as a maintainer it highlights where I probably need to take a look at when refactoring. Dates to me are a must. Commit message? I can live without.

2. Solution here is to flatten all tabs into a single navigational control

- This might not port well to mobile, and look clunky as a two- and three-level stack of tabs with no hierarchical relationships. Is there a half-way point that might work? I think the hierarchical relationships in Nikita's other (satiric) mockup of "Github XP"[0] are actually well represented and very clear.

Thanks Nikita!

[0] Windows XP satire (https://twitter.com/nikitonsky/status/1003593821723267072?s=...)


This is a great example of applying design thinking, and the reactions to it really highlight the limitations of design thinking. Requiring training or prior knowledge to use a tool is not en vogue, and so you must anticipate every possible outcome a visitor has. The personas that use Github live in the solution generation space. They don't need pre-ordained solutions. They need functions.


I use GitHub almost everyday, and I didn't really like the redesign, TBH. No doubt it doesn't help that I don't like "flat" interfaces in the first place.

I also disagree with some of his comments. For example, when he's talking about finding the Releases page from the Wiki, he says, "Releases are as much part of the Code as Issues or Wiki are." A Release is one specific version of the code, so the "Code" tab is the first place I'd look for it. Issues and Wikis are project level things that evolve separately from the code, so it makes sense that they're at the project level next to the Code tab.

The only thing I strongly agree with is that the project description should be outside of the Code tab below the name.

My only notable complaint with GitHub's UI is that it scales poorly. I'd really like if they made the entire middle content area 95% of the window instead of fixed width.


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.


The redesign seems to be geared toward beginners who are too intimidated to contribute to and explore large open source projects. I spend far more time in GH exploring my team's code bases, reviewing code, writing PRs and issues... and GH's layout is perfect for that.

I honestly believe GitHub is one of the best developer tools ever made. It's a joy to use and I have a major appreciation for their conservative approach to design refreshing.


The article started off with making some good points, but then seeing the suggestions applied made me dislike the result.

The single-navigation element looks cluttered, it's easier now with the hierarchy. The 'vanity counters' serve a purpose. Stars tells you people like it, forks tells you people might wish to change something. They are both valuable.

And the final result just looked horrible in my opinion. Design guides and standards for the 'general population' might not work in a setting where most users are 'power users'. I really wouldn't like it if Github took lessons from this blog.

And as a side-note, the fact that github's look hasn't changed much over the years is a _good_ thing. Look at hackernews - stay with a proven design.


I'm supposed to trust someone about design when they have that horrid yellow background? /s

Jokes aside, I was skeptical but I think the (2nd to last) result is really good. I see a lot of the logic behind it and I could get used to it. There is a lot of good thought that GitHub could draw from there.

The final theme changes were trash though. Something both his blog and new design fail at is contrast. I use a darkreader plugin because I'm young and don't want my eyes to crumble to dust before I die. That blue-on-white is not going to fair well when inverted (or however dark readers work).

In some sense, I think that github might consider his UX advice, but should ignore his style advice.


I'm on GitHub hours a day. Many things on there are libraries or tools. In those cases 90% of the people who come to the page just want to USE the code, not read it.

I see a lot of developers in that 90% get really confused because the README is below the fold. You're immediately presented with a directory structure that you don't care about.

I'd almost like to see different views for different purposes. Not sure what the answer is.

At work I made firebaseopensource.com to sort of re-skin GitHub with an emphasis on the docs, not the code. GitHub Pages is often used the same way.


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…


I was quite pleased at first but he completely lost me at removing the commit descriptions. I use that all the time. Without it, it is just a file system. And then flattening the design just for the sake of making it look more modern is a particularly bad idea.


First rule of design: Know your user. Second rule of design: You (the designer) are not the user.

I think the general criticisms here are because this designer didn't follow these 2 basic rules.


They have >500 commits on Github in the last year. I’m pretty sure that makes them a user: https://github.com/tonsky

First rule of life: don’t stereotype people (“designers aren’t coders”). Second rule: check before leveling ad hominems.


For what it's worth, 500 commits is <2 commits per weekday for a year, which seems pretty low for the kind of power user I would assume github is actually designed towards.


maybe work stuff ain't on github?


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


I was actually pretty pleased with this as a proposal right up until Problem 8

I actually use the description of commit and the time of commit quite regularly to figure out how active a project is.

If everything but the readme and maybe a contrib folder hasn't been updated in 6 years, I have concerns. Unless the commit message on one of those, say the contrib folder, indicates that adjustments have been made because the repo I'm looking at considers its work now be a solved problem space and I can see few/no issues or pull requests then I'm backing right out and looking elsewhere for a project that might address my particular problem.

Replace that information with a commit history that doesn't indicate to me where those commits got made (ie. Was it core code changes? A spelling mistake? Where are people actively working?) and a bunch of stats that I usually don't care all that much about and which are already available if I did really want them. Now the repo landing page becomea a chore to navigate.

However literaly everything up to #8 I actually think makes a lot of sense and is a small enough deviation from what is there that users aren't going to be immediately shocked.


> it’s time to fresh it up a little? Get rid of gradients, dirty washed-out colors, unnecessary separators, add a little more air. Something like this:

I'm not sure I agree with this. Gradients are not bad because not everything has to have a flat UI. Also, separators can be very effective if used correctly. IMO, I think a huge part of Github's success is it's user experience compared to Google code, Codeplex and others that did not continue.


Please don't remove the last commit touching a file. I personally love know what parts of the code have been last updated at a glance.

> Why? I don’t know. Commits often touch files for completely arbitrary reasons, so the last commit tells you almost nothing. I can’t think of any case when somebody would need that particular information.

Way to shove your opinions on everyone else.


No... just... No. Also, Flat Design and getting rid of all (even subtle) gradients is overrated.


> Commits often touch files for completely arbitrary reasons, so the last commit tells you almost nothing. I can’t think of any case when somebody would need that particular information

You sir are using git in a very wrong way it seems. Its not dropbox, you get to decide and see exactly what changed and why. Not just do a `git add .; git commit; git push`


I think I can see what the author meant. It's not about doing `git add . && git commit`; it's about things like changing the signature of a utility function and touching all files which use it. Such a commit arguably doesn't tell you too much about the file itself. I disagree with the author that it happens often enough to make the "last commit which touched this file" not useful, though.


I think it would be safe to assume that the author knows pretty well how to use git and github: https://github.com/tonsky/

Probably, while his own commit messages seem to be consistent and informative, he spent too much time looking at repos of other people, where it is not so.

Since I frequently have the same feeling when exploring potential dependencies for my projects, so yes, changing the Github UI to accept the status quo seems more logical for me, than trying to reeducate all the developers in the world to follow the universal guidelines for commit messages sensibility.


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.


> Commits often touch files for completely arbitrary reasons, so the last commit tells you almost nothing.

I actually use this feature frequently. I bet others do too. If I wanted to see the commits list, I can just click the commits tab.


Ditto, I do too and wanted to put my vote in for it.

Wanted to see see if others did too.

If your commit history is messy, then you have a different problem.


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.


The article says wraps up by stating the design hasn't lost any information but where's the fork count, watch count and other download options? Also, the lack of borders and flattening of button styles does not improve the design. Borders are even more necessary when data density is increased. Buttons, menus and links now have a variety of borders where they were consistent before.

The menu is marginally better but the extra density there makes the options run together, especially as counts increase, and lacks room for feature expansion. The grey background is useful also as it gives the page sections depth and context without having to label it. A all white background with various text sizes and lengths is not optimal for supporting more than the example design and projects using more text or with longer titles will suffer.

This design doesn't take into consideration how the homepage of a repo relates to the subpages of a repo. The article mentions showing more files yet the in the current design, file view one click away from the current homepage removes most of the account meta data and shows more files already.

This design also doesn't consider the logged out view which has a large call to action banner to get an account strategically embedded at the top of the code tab. This focal point is somewhat lost in the presented redesign and would likely require rounds of A/B testing to decide on a new content breakpoint for this business need.

5/10 - needs work


> where's the […] other download options?

In the “Get code as” section. You can see it was moved in there when solving Problem 11. It’s true that the fork and watch counts are missing though.


> You see, the nature of description and topics is that it’s important to get people to fill them when they first create their repo. After that, people rarely change them at all.

I have to disagree with this. I have had to change the topics and description very often on all my repos. Often the first description is the worst, because when I create a repo all I care about is getting the content up first. Later I start caring more about description and topics and particularly topics evolve over time as a project grows.

Overall I think the article was interesting, however I don't particularly like everything being squeezed as tightly together as possible. Having a few background colours or lines in a design to visually separate things out is actually quite nice. I don't mind if I have to scroll a bit further down to see more content. Scrolling is not an issue as the content is already there. Clicking is the problem. Modal popups or content hidden behind multiple server-client roundtrips is the issue. So yeah.. I don't mind a slightly longer page with better separated content.

Also his final design looks very inconsistent. Because all buttons and all other indicators look very different it is not clear anymore which is just a highlighted header (e.g. the issue counter) and which is an actual button which I can click (e.g. Watching counter).

Maybe a few good ideas to takeaway for GitHub, but I would hate them to adopt this design.


I think there is a design flaw with step 9: The code tab has been changed to "overview", but an overview is supposed to be a glance of something, not an authoritative source of data. So where's the authoritative source of files in the repository now? Are we supposed to be using the "overview" as a file browser too? I don't really want to see all that stuff on the right if I'm just trying to traverse some directories to get to a file.

I like all the changes prior to that one though.


I thought exactly the same thing. It replaced the files tab, whereas it should have been an additional tab, otherwise where would files be?


Github is a utility, a developer facing utility, not a consumer beauty product. As it works already, I would argue it doesn't need redesign, not many people are complaining its look.


100% this. Designers nowadays have trouble understanding the concept of utilitarian design. Nobody chooses a productivity tool for its looks. They choose it for its ability to solve a problem. The better it’s solving the problem the more appealing it becomes to an audience of potential users.

Aesthetics serve a purpose and can increase satisfaction, as well as the performance of a design, but they will never supersede functionality in a product like GitHub.


There's two main things I don't understand about the redesign and other comments here: what's wrong with nested tabs, and why is it confusing that "releases" is under "code"?

The latter makes sense because a release is basically just a snapshot of the code at a point that the developer(s) thinks it's in an acceptable state for users. Sure, it might reference Wiki pages or issues or contain binaries that aren't in the repo itself, but ultimately it's still directly related to code and at best only partially related to anything else.

As for nested tabs... how is that bad at all? Grouping related things together just makes sense. Maybe Github's current design isn't the best way to group them, but the concept of grouping itself is fine. Grouping related links together, assuming the links are grouped in an intuitive way, is far better than overloading users with a long line of different options. Maybe the current main tabs could be drop-down menus or something?

Also, as mentioned by some other people, I absolutely hate the current trend of making websites and apps be as plain white as possible. Separators, gradients, and soft colour backgrounds make it really easy to distinguish different content areas at a glance. The end result of this redesign is just a mash of text that looks like the CSS didn't load properly.

I'm also very surprised neither this redesign nor Github themselves have added a dark mode. Why do people enjoy staring at white screens for any length of time? I don't trust people who code with light themed environments.


Two nitpicks:

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.


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


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


The Yoda fork of the English language fixed this. The correct way is:

“Redesigning the Github Repository Page” shouldn’t the title be?


You can do what you like in British English - so, worst case, people will just assume you're from the UK.


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


That's the best argument I've ever heard for always put everything consistently after the closing quotation mark.


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


I've been ignoring that rule of English grammar for as long as I can remember; it makes no sense.


Design comes in three parts, at least, and I wonder if they should be done at different times, maybe even by different people:

(1) Wording. Consolidate "Create new file," "Upload files," and "Find files" into "Files: Create, Upload, Find." This is great. When you're in this zone, you are mercilessly paring down, pruning, merging.

(2) Layout. Do we need two levels of tabs? Should this go here or there? What things work well side by side? This is a relationship-analysis mood.

(3) Graphics. Borders, colors, gradients, etc. This is a creative mood, where you are building things up, giving them outline and skins.

If you just got done with Wording and then go to Graphics, you have this leftover pruning mentality. This might cause you to be overly minimalist in your graphic design, as this author was, in my opinion (and I'm a minimalist, who errs in the same way). I thought he did so great with the first 90% of the rewrite, and he echoed many of my thoughts when I'm working on something. But I agree with the rest of the people here who said he went too far in removing outlines and such that delineate components. It is a testament to Github's graphic design that it always looks fresh to me (but I agree a bit hard to navigate).


I really disagree with your top 3 problems, the rest is still not very convincing.

1. Nested tabs -> it's a better way to organize when you have too much content that should be grouped under the same tab. Nested tabs are found in lost of well-organized designs. I am a programmer and I do like hierarchies. I am uncertain about your statement of people normally don't like hierarchies. Maybe nested tabs don't suit your design, but I don't think it's a problem.

2. Redundant icons -> Of course when you stack them in the "intended images" with lack of spacing like that, they would cloud our views and harder to see. If you lay them out with good spacing, horizontally, they're much nicer to see. If you're using it often enough, you would remember the icons. I think you should keep the icons, push the non-regular items to a more option icon like ellipsis.

3. "Vanity counters" -> they're designed with different purposes. Out of the 3, I only care about Star and Fork. They're very good metrics and also good pride badges for public repos.

I do see there're good improvements compared to the old design like the file list, getting rid off the redundant commit description next to it, the stats.


I disagree with the commentary in step 1 that people hate hierarchies. They hate arbitrary, overly complex, and/or ambiguous ontologies.

For example, dividing a public library into fiction and non-fiction is something that provides arguable value (although some might argue which books should be on which side). Trying to figure out where something exists by the rules of the Dewey Decimal or Library of Congress or any of the many other classification systems out there can be maddening without experience.

Rather than starting with collapsing items, I believe it would be far more useful if there was consideration for how people use and intuit GitHub, and create the items from there.

For example: there are organizations and people who have projects, and projects contain facets like a code repository, issues, releases, and so on.

For example: the code repository contains branches which contain commits. Some commits are tagged, but all contain a file hierarchy. But since users care so much about the files, Github renders by default the latest commit in the project-default branch (such as master).

So perhaps a better view for files would be to make code itself navigable by breadcrumbs - top view is branches and tags, a branch/tag view winds up taking you to a commit history, and a commit takes you to the file view. You just default to a place inside the breadcrumbs when you go to the root of a project and select to view code.

Step 8 seems to be where it finally broke down for me. The file view lost a lot of information that people rely on and want, without consideration for why they rely on it, or how they can get it back if they need it.


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?


Author's UX/UI credibility went out the window as soon as I saw black on yellow.


I need those Files Description because I'll know immediately which file/directory has changed recently.

The UI you propose cater to your needs. It's just that.


I think at the end of the day, this redesign doesn't seem to consider how the site is used. This redesign constitutes an application of heuristics, without a cohesive story around how the site should be used. If you start with "what does a user want when they go to a repository" rather than "how could I iterate on this design", I believe you'd end up with different results.


> http://tonsky.me/blog/github-redesign/60_icons-removed.png

Why should a user without any background in coding / git, care about the branches when opening an issue? Or individual commits? Not the mention that the number of commits may change depending on the selected branch, but the issues and releases stay the same, which is something the author does not talk about.

> If you are a programmer, you might be surprised but other people normally don’t like hierarchies.

Citation needed.

One of the big benefits of a hierarchy (be it in UI design or on a political / social / corporate level) is that on any level, you really don't have to think about the levels above or next to you that much, and thus even individuals with a very limited skill set can be productive members of this hierarchy. The anarchic approach of "everything is accessible to anyone everywhere" taken here just excludes specialists from using a GUI productively.


> Citation needed.

All the popular modern interfaces don't use trees, they use lists and lists of lists. Technically those are trees, but not to users, since they're only exposed to 1 level at a time.

And regarding the "anarchy" is solved another way: searching and sorting, à la Knuth.

The most successful interface of all time, Google, has 1 input and 1 button and it returns a list of things.


Section 8 was my favorite redesign. Section 11 was okay. I could see the utility in it. Section 12 would push me off the platform entirely.


I don't know. Don't get me wrong - I like most of the changes. The thing I miss in the final result you create is the presence of "last edited date".

I am a console guru, as such I actually run most of my github (yes github, not only git) interactions from within Vim or the "hub cli".

When I need to actually visit Github, the primary thing I do is look over the shoulders of a colleague and pointing out specific files. It is super convenient to have the "16 minutes ago" at the end of each file or directory, since I can basically just ask the colleague I'm helping to follow the "16 minute" pointer as a rabbit hole to the file in question (without bothering to remember the actual file name).


This was really good, up until the 'refresh'. Why get rid of most of the visual structure right after you spent all that effort making it cohesive?

I especially like the code + commit activity + stats in the overview page, when visiting a new repository the initial code view is almost never what I want to see.


Congrats on this - there are some really good ideas here that would definitely improve Github further. IMHO, there is still room for improvement:

- Mobile - Github's mobile experience is less than desirable, proposing a mobile-first approach here would be amazing;

- Tabs - having a row with more than 10 tabs won't help much on improving the navigation, not to mention localization;

- Overview tab - this is a great idea, but it would depend on the user type. If you are the owner or contributor to the repository, you'd most like benefit from the glanced overview page, but if you are a regular user, you would want to see the Readme.md view to decide if the repo is what s/he is looking for or if it's well documented.


The author logic for the header and tabs seems pretty reasonable because the arguments come from ideas from most UI kits around, but after the break the article clearly states a lack of knowledge on git and how github was designed around that.

Thats one take i`d criticize on github design, it does fail to explain how git or github works, but I think the platform was designed as a hub for git users and does great on that.

I think we can agree comparing to other similar plataforms github has the most straightforward design, so much that is used beyond coding. Some people are running communities on it, with colaborative forums using issues and plain text documents formatted using markdown. Its quite remarkable.

The intent of the article was good but as some of us programmers would say: if it aint broke, dont fix it. :)


I hope GitHub stakeholders will never read that article. It's full of nonsense. The author doesn't know what he's talking about in this particular case.

Commits, branches, releases, contributors belong exclusively to Code! There are no releases in Wiki. The GitHub design is perfect and it should stay like that forever :-)

I hate those designers who try to "fresh up" things every single month. Is it because they cannot create something valuable? I was just getting used to the latest icons in my IDE and next month they "fresh it up" and I have no idea what is what.

GitHub has been around for years, it gets the job done, everyone is used to it and knows how it works. Let it stay like that!

The only thing that I'm missing sometimes is file tree. But one can get it with the help of Octotree extension.


> The traditional Windows File Explorer, together with macOS Finder, have established a simple pattern for file browsing: files on the left, details on the right.

I think the author is a very young guy that doesn't remember computing pre-Windows. Probably everything before Windows has used this pattern...

Even more, it's a perfect example of trying to fix what's not broken. The result will be something else, not better, not sure if not worse, but why change it?

How am I supposed to buy the argument that a programmer has a problem with understanding the difference between a fork, a like, and a watch request? Wasn't GitHub meant for programmers?

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

In other words, push through the pain. You'll like it.


I hate how they present is as "problem" they are trying to "solve". I don't have any of these problems and I use Github almost daily.

Why someone always has to create artificial problems and re-design and re-invent something which don't need any change? And it is not rare that they make things worse from usability standpoint.

A similar example (not layouting though) is also that flat design in iOS. Buttons which have no border and can't be distinguished from labels. Flat, solid colors. If you look at Windows 1.0, it looks nicer than current iOS design, it even has an innovative border around buttons, rounded! So why are designers gong back and making it worse than it had been at the beginning of graphical UI design...


I don't really like the end result of all of the changes; it seems a lot busier than the current UI.

Maybe I am just really used to the current UI, but I don't really feel like I need to see the codebase, last N number of commits, and language statistics all at the same time. I prefer the current set up in that the language stats are incredibly minimalistic and the current list of commits are viewable if you click on commits.

I also think putting the navigation all one line is a bit cumbersome in that you would have to scan all of the links horizontally. I feel as though this makes it harder to find which link I need to click on.

I do like that flat design on some of the buttons but overall, I feel like the redesign is difficult to take in.


I really enjoy this kind of articles even if I don't necessarily agree with all changes that the author made. Sometimes looking at the old/new comparison makes me consciously think about what makes it a good design for me and what doesn't.


I agree with several of the redesign suggestions, basically right up to the ending where the entire thing collapses into a wash-out of overdone white spacing that makes the entire layout a carnival of chaos without strong separation.

I can hardly believe the author went through and carefully tried to improve an already highly effective layout, mostly did a sound job at it (or at least made an argument for their approach), and then destroyed it all in some kind of strange burst of what the hell in conclusion.

It's like someone made a mistake at the end and accidentally dropped Github into a bad css framework or design you might buy for $5 on Envato. The separators aren't unnecessary, they're critical.


I was so on board with change progression until the final mock - floating, borderless sections on a sea of white is profane.

Big fan of the screenshot under problem 10 however and would love to see Github implement some of the improvements on vertical space usage.


I am completely fine with the final result, except the three columns. That stuff is completely useless to me. What I want is this: README and Issues/PRs front and center. If I want to view the code I'll use OctoTree or the `T` shortcut. There's absolutely no reason to be viewing the code from the main page in my opinion. Most of the time I'm visiting GH is to view the readme, the issues, the prs, or the wiki. I never navigate through the code using their 'file browser', as it's terrible and you can't even see the hierarchy. OctoTree is much better for that.


I liked most of the changes, but it lost me with the final redesign. Three columns without much separating whitespace is quite jarring to follow. Maybe that would work better on a larger screen with some padding between the columns.

Fun exercise, anyway.



This is clearly a redesign done by someone who doesn't use GitHub, and doesn't look at anything but the main screen or why it is the way it is - especially when you start digging into the rest of the UI.

The tabs they want to take away from the "code" screen have little or nothing to do with the other main tabs, that's why they're not cluttering up the main nav bar (which doesn't fit into the author's screenshots.

No one cares about the description of the repo if they're trying to interact with the wiki or the issues modes, that's why it's in the code/main section.


> This is clearly a redesign done by someone who doesn't use GitHub

They have >500 commits on Github in the last year: https://github.com/tonsky


Really well thought out. I love this. I've never realized 80% content on the first page is completely useless.

I think adding the readme to above the commits/stats would be a good idea. Perhaps make it ~500px and expandable.


What I really want to see is not having to click on 'Show Desktop' whenever I'm on a phone to be able to read a whole README file. I just want to see the README first, all of it.


    Problem 3: Vanity counters 
    This is the “vanity menu”:
    The thing with vanity metrics is that there should be just one. One metrics is simple to understand and focus. Two or three split attention, making everything weaker.
Each one of these metrics is important to me - I judge a project by the numbers in each of these, and they have very different importance depending on the size of the repo. Please don't "simplify" this.


The GitHub designers are infallible GOATs, how dare this upstart - wait, WAIT. This is actually pretty good. Designing for desktop width makes sense because GitHub uses a relatively independent design on mobile [0].

I'd like to find a useful alternative to commit messages on the Code page that was still per-file focused.

[0] https://photos.app.goo.gl/arU8HrUUw9yQgQyc8


I think the problem when it comes to any UI design is it's all personal choice.

I was going through these comments and most everyone here disagrees with one or two things and other's agree. Art is a subjective thing and I think ultimately at the end of the day it's about giving the developer more options and letting them decide what makes sense to them.


This deprioritizes the readme even more (and it's already too much; why can't I see it all by default in the mobile view?)


I am still amazed that there is no easy builtin way to sort your repositories by date on Github.

Also, how do I filter all my repositories to be the ones I created from scratch not the ones I forked? EDIT: This one is easy just use Sources Filter(strange name but ok).

With 300+ repos it is getting rather unmanageable.

Sure there is an API for creation date but that is just silly.


It feels like you didn't interview any real-world users here. I think the end product might have turned out quite a bit differently had you done the leg work required for such an undertaking.


Despite the fact I like some of the changes presented there, one particular detail has shot me: lack of understanding why github has put commit messages in file list and removing it - this might be a harsh opinion, but proved to me that the author doesn't fully understand how most users (developers) are using GitHub.


I don't agree with repository overview. Most people visit home page are not maintainer. They don't care much about commits and statistics.

What they do is reading the README.md or reading code without cloning them to their machine. Perhaps commit message is not important, but the update date reflects how active the repository is.


To me this sounds like a prime opportunity to have two repo pages: one for contributors/owners, one for everyone else, and the option to toggle the view for each account per repo.

The danger would be overcomplexity/confusion, but if designed to match eachother well with different priorities, it could work. Still, the singular view no matter who you are is certainly a nice feature that may not be worth getting rid of given how universal the repo page design is.


Fun article to read, and has some interesting ideas!

In case anyone else is interested I wrote a similar style of article about refactoring GitHub’s interface a few years ago too:

https://ianstormtaylor.com/refactoring-githubs-design/


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: