Live data from Hacker News

Redesigning GitHub Repository Page

tonsky.me

221–230 of 315 posts

Re: Redesigning GitHub Repository Page

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

Re: Redesigning GitHub Repository Page

#222
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…

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

Re: Redesigning GitHub Repository Page

#223

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

Re: Redesigning GitHub Repository Page

#224

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

Re: Redesigning GitHub Repository Page

#226

Earlier quoted context omitted.

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

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

3) Most developers are absolutely awful graphic designers.

Re: Redesigning GitHub Repository Page

#227

Earlier quoted context omitted.

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

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

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.

Re: Redesigning GitHub Repository Page

#228

Earlier quoted context omitted.

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

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

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

Re: Redesigning GitHub Repository Page

#229

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

Re: Redesigning GitHub Repository Page

#230

Earlier quoted context omitted.

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

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

[deleted]
Post reply on HN