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.
Redesigning GitHub Repository Page
11–20 of 315 posts
Re: Redesigning GitHub Repository Page
#12Two 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?…
> 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.
Re: Redesigning GitHub Repository Page
#13I'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.
Re: Redesigning GitHub Repository Page
#14I really thought this article would make the readme much more prominent.
Re: Redesigning GitHub Repository Page
#15Most 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?
Re: Redesigning GitHub Repository Page
#16No. 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.
Re: Redesigning GitHub Repository Page
#17> 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.
Re: Redesigning GitHub Repository Page
#18Section 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.
Re: Redesigning GitHub Repository Page
#19I 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.
Re: Redesigning GitHub Repository Page
#20No. 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.