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

111–120 of 315 posts

Re: Redesigning GitHub Repository Page

#111

Post by ken »

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

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.

Re: Redesigning GitHub Repository Page

#112

Post by bpye »

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

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.

Re: Redesigning GitHub Repository Page

#113

Post by alan_n »

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.

Re: Redesigning GitHub Repository Page

#115

Post by MrStonedOne »

structural wrote: post #82
jbergknoff wrote: post #61

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…

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

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

Re: Redesigning GitHub Repository Page

#116

Post by MrStonedOne »

smazero wrote: post #91

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

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.

Re: Redesigning GitHub Repository Page

#117

Post by userbinator »

dcosson wrote: post #77
JoshTriplett wrote: post #9

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…

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.

Re: Redesigning GitHub Repository Page

#120

Post by tenryuu »

MrStonedOne wrote: post #116
smazero wrote: post #91

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

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

Post reply on HN