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

51–60 of 315 posts

Re: Redesigning GitHub Repository Page

#51

Post by m1el »

So here's what I suggest to the author: go to the "Issues" page for some project, and see the effect of this redesign.

From my perspective: there's now a lot of useless tabs on the top (commits/branches/releases), the repository description will either take extra space OR will disappear and the tabs are going to shift.

- Getting rid of icons: OK

- Moving description over tabs: bad

- Shuffling tabs around: bad

- Different info instead of code details: meh

- Vanity counters: OK

- Changed style/color-scheme: bike-shedding / meh

Opinionated summary: hit and miss.

Re: Redesigning GitHub Repository Page

#54

Post by adventured »

I agree with several of the redesign suggestions, basically right up to the ending where the entire thing collapses into a wash-out of overdone white spacing that makes the entire layout a carnival of chaos without strong separation.

I can hardly believe the author went through and carefully tried to improve an already highly effective layout, mostly did a sound job at it (or at least made an argument for their approach), and then destroyed it all in some kind of strange burst of what the hell in conclusion.

It's like someone made a mistake at the end and accidentally dropped Github into a bad css framework or design you might buy for $5 on Envato. The separators aren't unnecessary, they're critical.

Re: Redesigning GitHub Repository Page

#56

Post by grblovrflowerrr »

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 two natures of Github as a tool for software development and Github as a social coding site are often at odds. Some ways this could be reconciled:

- greater end user customization of the UI layout

- an option to enter a different UI(contributor UI) for repositories you contribute to/own

- make the contributor UI an enhancement on top of the current UI(perhaps a new darker tab bar)

- related to the above, separating out the discovery part into a separate app

In general, I am in favor of greater customizeability in my professional tools, especially something I use as much as Github. I think one reason we as software developers don’t add a lot of end user customizability to our UIs though, is that it adds a ton of complexity to the UI code. This suggests there is opportunity to explore new UI development paradigms and libraries that have end user customizability as a primary concern, instead of a bolted on after thought. I’m curious if anyone is working on such a project.

Re: Redesigning GitHub Repository Page

#57

Post by icebraining »

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

Re: Redesigning GitHub Repository Page

#58

Post by legitster »

I was quite pleased at first but he completely lost me at removing the commit descriptions. I use that all the time. Without it, it is just a file system. And then flattening the design just for the sake of making it look more modern is a particularly bad idea.

Re: Redesigning GitHub Repository Page

#59

Post by agumonkey »

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 feel conflicted. There's a value to show the log graph on project's home. It feels that the main emphasis is not really the static nature of source but the contribution you can make to that tree (as in branches history graph).

Re: Redesigning GitHub Repository Page

#60

Post by RussianCow »

MereInterest wrote: post #44
Memosyne wrote: post #27

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

Agreed. I was on-board with most of the changes, but that one removed all visual distinction between elements. It became a load of black text on top of a white background with no separation between semantically different elements. On a related note, Gmail's latest redesign for Android made the exact same blunder when viewed in the compact density. Just sender/subject/sender/subject with very little indication of each…

Lack of visual distinction is a general problem with the current design trends. Even Apple suffers from it at times—in Xcode, it's impossible to tell whether certain elements are interactive (buttons vs passive status indicators) without clicking on them.

The thing that drives me up the wall is when text inputs are not made obvious. Google in particular is notorious for not giving any indication that something is a text box, as opposed to just static text. I can't count the number of times I have tried to focus and type into something that I thought was a text field, only to discover that nothing was happening.

Post reply on HN