Live data from Hacker News

Redesigning GitHub Repository Page

tonsky.me

141–150 of 315 posts

Re: Redesigning GitHub Repository Page

#141

Earlier quoted context omitted.

That seems like a great idea in principle, but for most small projects the GitHub page /is/ the documentation. If that weren't the case, you wouldn't see half a dozen links to GitHub pages to show off projects on HN each day. It's all very well to talk about ideals, but you can't ignore reality in the process. You're right, though, that you shouldn't have to scroll past it every time. I don't really know what the sol…

If you've read one README on Github, you know to scroll down to see it on every other project. I would argue that it's not a steep learning curve, and it's not like the hide the scrollbar... we scroll in other websites without issue when we are looking for content, especially with ads being most of the content above the fold these days.

I agree it's not much of a learning curve, but neither is learning which icon represents a commit. This entire discussion is about minor details.

Re: Redesigning GitHub Repository Page

#142
> 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 need to. Icons aren't only for the illiterate or first-time users... they create a signpost for repeat users to scan for without reading a word. As long as you consistently use the same icons and they make at least a little sense, they can be useful (I agree that some of Github's don't make much sense at all though).

>I mean, Icon + Label + Counter make for a symmetric and weak composition:

It's best to refrain from insults during critique, but this is flat out dumb. Completely unfounded. No evidence. The composition is "what is it" and "how many" — it makes perfect sense.

>The thing with vanity metrics is that there should be just one. One metrics is simple to understand and focus.

Again, no. This is how _you_ use it. You've done no research. I want to see forks because I want to know how many people are potentially engaged in _doing_ something with a repo. Stars matter less to me because there are some repos that just have a lot of stars because someone wrote an interesting article about it once. (I do think stars and watching is a bit redundant, I personally have no need for both but my personal experience does not solely dictate what the product needs to be)

> Watch button

Again, no. `Watch` is an action. If I click the dropdown I expect to have options for "watch". "Not watching" simply adds words and makes me put forth a little cognitive effort (minimal but it's there) to parse what the opposite of "not watching" is. You are adding the need to think more, not less.

--

Honestly I'm too exhausted to continue. This redesign isn't well thought out at all. At this point I skipped ahead to the end, and honestly it's just a garbled mess. You don't understand the product or its users. If you were my student (I'm a design professor) I'd give you credit for the effort, and the visual design is fine (though are you trying to trick me into thinking that making corners more round is meaningful?)... but there's an endless mountain of straight-up bullshit to call out here.

Re: Redesigning GitHub Repository Page

#143
I'm on GitHub hours a day. Many things on there are libraries or tools. In those cases 90% of the people who come to the page just want to USE the code, not read it.

I see a lot of developers in that 90% get really confused because the README is below the fold. You're immediately presented with a directory structure that you don't care about.

I'd almost like to see different views for different purposes. Not sure what the answer is.

At work I made firebaseopensource.com to sort of re-skin GitHub with an emphasis on the docs, not the code. GitHub Pages is often used the same way.

Re: Redesigning GitHub Repository Page

#144
post #102

But maybe it’s time to fresh it up a little? Get rid of gradients, dirty washed-out colors, unnecessary separators, add a little more air. No, no, no , NO!!!11 I've had it with these "sea of floating text on an expanse of white" redesigns, seeing yet another one follow this mindless trend just disgusts me thoroughly. The lines, subtle gradients, and other affordances of the old design serve to organise and direct you…

_If you feel disoriented, give it a minute._ The guy spends a very long article explaining how things could be laid out easier to orient yourself in and then asks you to give a minute to get used to his color scheme.

This criticism seems somewhat unfair. I believe they were implying that familiarity with the old design will strongly bias your initial reaction, and giving it just a few more seconds will help to avoid that trap.

Re: Redesigning GitHub Repository Page

#145
I use GitHub almost everyday, and I didn't really like the redesign, TBH. No doubt it doesn't help that I don't like "flat" interfaces in the first place.

I also disagree with some of his comments. For example, when he's talking about finding the Releases page from the Wiki, he says, "Releases are as much part of the Code as Issues or Wiki are." A Release is one specific version of the code, so the "Code" tab is the first place I'd look for it. Issues and Wikis are project level things that evolve separately from the code, so it makes sense that they're at the project level next to the Code tab.

The only thing I strongly agree with is that the project description should be outside of the Code tab below the name.

My only notable complaint with GitHub's UI is that it scales poorly. I'd really like if they made the entire middle content area 95% of the window instead of fixed width.

Re: Redesigning GitHub Repository Page

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

Github is certainly used by developers. But I bet 95%+ of views of repositories’ start pages are made by “consumers” of that code.

At least in my workflow, I visit dozens of those pages every week to, for example, choose between alternative libraries.

My own projects’ index pages are definitely a small percentage of the total. And for those views, I would still prefer this redesign that gives me a quick overview of what’s happening.

Re: Redesigning GitHub Repository Page

#147
post #112

Earlier quoted context omitted.

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.

If the whitespace only change comes after the refactor, then the last commit message is "fix whitespace."

Re: Redesigning GitHub Repository Page

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

Especially when it comes to web applications, I'm starting to dread customization.

Just one example: One of the worst platforms/applications I have ever used is built with Sencha/ExtJS, and it causes a ton of bugs and friction. But hey you can move your windows around and resize them, doesn't that make up for features that don't work?

Re: Redesigning GitHub Repository Page

#149
post #138

Earlier quoted context omitted.

> When I'm working with a GitHub project, I commonly want to load up the page and navigate to some files. If not, it's usually not much scrolling to get down to the README. The solution I'm using currently for the git repos hosted on my personal site [0] is to show the projects file tree above the README, but allow it to be collapsed by clicking on the projects root directory. Originally, the project tree was collaps…

Do you mean that your metrics showed that few people were expanding the tree, so you made it expanded by default? I would interpret the data as meaning that most people don’t care about the list of files, so it’s better for them to be hidden by default.

> Do you mean that your metrics showed that few people were expanding the tree, so you made it expanded by default?

Correct, after it became expanded by default, the hit rate for project files was dramatically higher, showing that users did care about viewing the files. Perhaps the UI could better indicate that it can be collapsed/expanded, but it could also be that it doesn't match the common UX found on the big sites like GitHub that users have become accustomed with.

Re: Redesigning GitHub Repository Page

#150
I think at the end of the day, this redesign doesn't seem to consider how the site is used. This redesign constitutes an application of heuristics, without a cohesive story around how the site should be used. If you start with "what does a user want when they go to a repository" rather than "how could I iterate on this design", I believe you'd end up with different results.
Post reply on HN