Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Redesigning GitHub Repository Page

tonsky.me

Post reply on HN
Print view View original

61–70 of 315 posts

Re: Redesigning GitHub Repository Page

#61

Post by jbergknoff »

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.

Re: Redesigning GitHub Repository Page

#62

Post by Forge36 »

scott_s wrote: post #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…

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.

Re: Redesigning GitHub Repository Page

#63

Post by Gaelan »

icebraining wrote: post #57
q3k wrote: post #16

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.

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

Re: Redesigning GitHub Repository Page

#64

Post by shawnz »

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.

Re: Redesigning GitHub Repository Page

#65

Post by sc11 »

jdminhbg wrote: post #42
wyattpeak wrote: post #25

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?…

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 no…

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

Re: Redesigning GitHub Repository Page

#66

Post by makecheck »

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

Re: Redesigning GitHub Repository Page

#67

Post by wyattpeak »

X-Istence wrote: post #36
wyattpeak wrote: post #25

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?…

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.

Re: Redesigning GitHub Repository Page

#68

Post by seniorsassycat »

abhchand wrote: post #50

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 doe…

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.

Re: Redesigning GitHub Repository Page

#69

Post by RussianCow »

thinkloop wrote: post #46
Aeolun wrote: post #21

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 t…

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,…

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

Re: Redesigning GitHub Repository Page

#70

Post by tathougies »

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.

Post reply on HN