Live data from Hacker News

Redesigning GitHub Repository Page

tonsky.me

271–280 of 315 posts

Re: Redesigning GitHub Repository Page

#271

Earlier quoted context omitted.

My intention with discussing the meaning of skeuomorphism is to also convey that people talk without knowing what they are talking about. Being vaguely angry about "young designers" and their "hip flat interfaces" is a common trigger on HN. I've seen it here countless times, and its rarely insightful. The argument is rooted in a the fallacy that designers only care about making "pretty" things. Likewise, I've also he…

> Being vaguely angry about "young designers" and their "hip flat interfaces" is a common trigger on HN. No, the triggering part of your message was the "nostalgia" claim, which isn't supported by the evidence. Even young people typically have an easier time finding their way around interfaces with an older visual design than a modern flat design (all else being equal). This has been tested. The fact that you claimed…

Would you mind pointing to a good resource with a brief write up on the state of the art of good UI, as you pointed in your first comment? I'd also like to read up on the shadow stuff a bit, on how to do it right.

Re: Redesigning GitHub Repository Page

#272

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…

> Commits often touch files for completely arbitrary reasons, so the last commit tells you almost nothing

That is mostly true if you are casually browsing a repository you are interested in. It is definitely not true if you are a contributor/owner of the repository.

Re: Redesigning GitHub Repository Page

#273

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…

Yeah, I was totally with the author for steps 1-7, but I have problems with the last four steps. Personally, I think step 9 shows exactly where the author is a bit out of touch. He seems to see GitHub as a sort of code social media site where statistics about the repository are just as valuable as the code itself. In some cases (especially open source), I can see that being kind of true, but I think GitHub gets far m…

Yeah, that second line of development went in another direction with different guiding principles.

If the first set of changes can get positive reviews here, maybe they'll get merged.

The second line could benefit from some questions about its targets and see how they align/diverge with the aims of a common vcs UI model. I wonder how this matches other UIs.

In any event, a roadmap would help so we could put this in a broader view of where and how it fits in to our needs. See also, https://github.com/isaacs/github/issues/

Re: Redesigning GitHub Repository Page

#274
post #220

Earlier quoted context omitted.

I’m a big fan of nested hierarchies. But hierarchies only work when they are logical. And on GitHub they patently aren’t: For instance, I’ve got to search for the Releases tab every single time . Its placement below “Code” makes no sense whatsoever. And even though I know this, I’m still disorientated every time. The same is true for some of the other tabs. I agree with you about the Issues and PR tabs, but I think i…

As commenters point out in sibling threads, there is a logic to the hierarchy: the top is GitHub operations and concepts, while the bottom are git concepts. (“Releases” are really just tags.)

Releases aren't just tags, they have files and descriptions, it's a whole new things that Github offer. Tags are available through the branch dropdown (this is where I get them when I need them) and they do have a tabs for it in Release (I do see even more so what the article was talking about with the confusion that hierarchy bring), but when I go to the Release page, it's to get an officially packaged release, nothing else.

Re: Redesigning GitHub Repository Page

#277
The author logic for the header and tabs seems pretty reasonable because the arguments come from ideas from most UI kits around, but after the break the article clearly states a lack of knowledge on git and how github was designed around that.

Thats one take i`d criticize on github design, it does fail to explain how git or github works, but I think the platform was designed as a hub for git users and does great on that.

I think we can agree comparing to other similar plataforms github has the most straightforward design, so much that is used beyond coding. Some people are running communities on it, with colaborative forums using issues and plain text documents formatted using markdown. Its quite remarkable.

The intent of the article was good but as some of us programmers would say: if it aint broke, dont fix it. :)

Re: Redesigning GitHub Repository Page

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

This is a great point. The author completely disregards the fact that this is a tool, and a battle tested one at that. Moreover, GitHub has presumably done a lot of testing and analysis on how people use and navigate their site. The fact that author disregards this fact (or, likely possibility) shows a stark lack of understanding in the product side of design. Don't get me wrong, design and it's principles are important and I appreciate pretty stuff as much as the next user. But use those to inform your new products or features, don't assume that "bad" design is the result of poor design choices, but actually smart product decisions by a team with a good understanding of how users actually use the tool. Maybe I'm giving too much credence to GitHub's product team, but the author gave none so I figured I'd toss a vote of confidence their way.

Re: Redesigning GitHub Repository Page

#279
post #106
post #62

Earlier quoted context omitted.

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.

That noise is the exact reason why I think the design over the years hasn’t strayed away as captured in the screenshots. One of my favorite parts of using GitHub is that the design is clean and easy to navigate. Throwing twenty widgets on there and cramming everything on top of each other adds clutter and distracts users from being able to visually navigate the page. I can’t speak for everyone, but given the chance,…

Thanks for the feedback on GitLab’s UI density. We’re working to improve the aesthetics and usability of our system, and feedback from the rest of the community helps us do that. If you have specific feedback, please feel free to share more here.

Re: Redesigning GitHub Repository Page

#280

> If you feel disoriented, give it a minute. Once you are used to it, you might notice it’s actually easier on the eyes and a bit lighter. I've been staring at it for 5 minutes now and I'm still disoriented. The borders and gradients gave the design an attractive depth and by removing them you ruined for me. The whole high-contrast/no-gradient thing is also one of the reasons I dislike using Gitlab. It was all going…

Thanks for the feedback on GitLab’s design patterns. We’re working to update our design system, so feedback like this is helpful, and we’ll take it into consideration as we make updates. If you have additional feedback, please feel free to share it here or in a GitLab issue.
Post reply on HN