Live data from Hacker News

Redesigning GitHub Repository Page

tonsky.me

171–180 of 315 posts

Re: Redesigning GitHub Repository Page

#171
post #77

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

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

> 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

Re: Redesigning GitHub Repository Page

#173
Github is used for at least two things: (1) finding new repositories and check how actively they are developed and (2) actively developing repositories.

This design fits well for (1). But for 2, it performs badly. I need all the files, the commits etc if I'm working on the repository.

Re: Redesigning GitHub Repository Page

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

Re: Redesigning GitHub Repository Page

#176

> if you put too many icons in a row and they are all different, they won’t work. uhh what? says who? where's the source of this? This is only the case if your icons don't look different enough. In the example those icons aren't great because they've overly complex and easy to mix up. >you won’t come up with a great icon for a commit. Or a release. Or an issue. Or a license. You can, and you also don't necessarily ne…

I’m glad to see a designer agreeing with all of the developers.

Re: Redesigning GitHub Repository Page

#178

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

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

Re: Redesigning GitHub Repository Page

#179

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

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.

Post reply on HN