I am completely fine with the final result, except the three columns. That stuff is completely useless to me. What I want is this: README and Issues/PRs front and center. If I want to view the code I'll use OctoTree or the `T` shortcut. There's absolutely no reason to be viewing the code from the main page in my opinion. Most of the time I'm visiting GH is to view the readme, the issues, the prs, or the wiki. I never navigate through the code using their 'file browser', as it's terrible and you can't even see the hierarchy. OctoTree is much better for that.
Redesigning GitHub Repository Page
301–310 of 315 posts
Re: Redesigning GitHub Repository Page
#302Earlier 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.
> in my opinion, a whitespace only change should be a seperate commit
yeah and now your 'most recent commit' is 'fix whitespace' instead of whatever your relevant commit message is. No matter how disciplined your colleagues are, commit messages describe what was done and sometimes what was done is just cleanup or refactoring.
Re: Redesigning GitHub Repository Page
#303But 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…
I thought some of his suggestions were pretty decent. But then he just threw everything away by mucking around in the Code, I mean Overview tab. His last design, without the guiding lines, make it look like jumbled shit pie.
At the time of this posting I got 13 points for expressing a popular opinion. I'm not sure it deserved it. Its not that I disagree with what I wrote, but it could have been more thoughtful. This kind of thing just reinforces my feeling that HN's vote system is broken.
Re: Redesigning GitHub Repository Page
#304I 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?…
As a developer, the README is useless, I am usually on a Github repo to start looking at code, and I don't want to have to first scroll through a README. IMHO documentation websites and the like is where people should get their first feeling for a project, that is where the README should be.
Hilariously I feel the exact opposite. I'll use OctoTree if I want to view the code, as github's code view is absolutely horrendous. It's like when your using Mac's Finder, it doesn't make any sense.
I visit the main page of a repo to see the Readme or to go straight to the issues/prs page. I'll use OctoTree to view code.
Re: Redesigning GitHub Repository Page
#305Earlier quoted context omitted.
As a developer, the README is useless, I am usually on a Github repo to start looking at code, and I don't want to have to first scroll through a README. IMHO documentation websites and the like is where people should get their first feeling for a project, that is where the README should be.
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…
A small "Read the full description"-link to the #readme anchor below the inital short description probably would work wonders here.
Re: Redesigning GitHub Repository Page
#306Probably gonna be lost in the sea since this is 2 days old, but here goes anyway:
- I agree maybe releases could be put to the top level menu, but not Everything. Now It's way too hard to parse and took me much longer to find things I need. I use the "Refined Github" extension on my firefox and that's the only tab it adds, cause it makes sense.
- Moving description and tags up top by repo name, good decision. I like that one a lot.
- This fear of hierarchies is why I struggle with many redesigns. Yeah, everything being out there is fun, but it always takes forever to find things. Once you have used the old for a week much of it is muscle memory.
- An example of what I feel is an issue that keeps sticking in my brain, your clone/download area. The Green dropdown is easy to see, Opens up to let you do all you need, and is very explicit. "Get Code As ..." Is confusing, easy to overlook, and doesn't look like where you'd download an easy .zip file or open it in a desktop app. There's gotta be a middle ground, which is likely separating the two things again. Theirs confused people looking for the clone link, somehow, but yours looks NOTHING like a download button for a zip file.
- Getting rid of the second set of tabs on the code tab honestly hurts a lot of different use cases to benefit only the use case of a casual browser. I'll often look around at projects to see if I can lend a hand, and being able to see the code color bar under the buttons allows me to see how much my skills are useful to the project at a quick glance. I know my colors, and if I see a new one, a quick click informs me. Additionally, when seeing if I can use a library for work, the easy, bit view of the license is crucial. Your design had me searching for almost a minute, and still, when I go back I can't find it immediately.
- Removing quick editing from the description and tags is a mistake too. Just cause it doesn't happen often for you, doesn't mean it should be hidden. I'm certain there'd be tons of people who get really confused by it being moved and would never think of it being put in a catch-all settings page.
- Stars, forks, and watching, I'll agree with these changes pretty easy. Makes sense.
- Please don't get rid of the colors. Add more, change em up, whatever, but don't go soulless white, black, grey, blue, hints of red. My eyes have a much harder time parsing your dense, separation-less page than it would a bright, saccharine mess that at least differentiated everything. This feels like facebook or something else lacking joy, give it a light drop shadow or background color if you wanna lose the borders! Seriously, take your end design and give each of the three columns a little border radius and a slightly offset drop shadow, add a light, simple background color on hover of each folder/file/commit, and I can at least stomach the rest of it.
Re: Redesigning GitHub Repository Page
#307Congrats on this - there are some really good ideas here that would definitely improve Github further. IMHO, there is still room for improvement:
- Mobile - Github's mobile experience is less than desirable, proposing a mobile-first approach here would be amazing;
- Tabs - having a row with more than 10 tabs won't help much on improving the navigation, not to mention localization;
- Overview tab - this is a great idea, but it would depend on the user type. If you are the owner or contributor to the repository, you'd most like benefit from the glanced overview page, but if you are a regular user, you would want to see the Readme.md view to decide if the repo is what s/he is looking for or if it's well documented.
Re: Redesigning GitHub Repository Page
#308First 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…
I don't - I use this quite a lot in the current view to see how active they still are. The commit log is maybe nicer - but as an external user of something hosted on GitHub - that level of detail is actually not that interesting. A "last updated" would be more useful.
If you would get the commit/pull req/issue list in your default view when you have commit rights on - or have been contributing to a repo, sure, seeing the commit/pull req/issue log could be an interesting information stream in that situation.
But then lastly - the other statistics? It just creates an information overload. I prefer a cleaner look with a single focussed view.
Re: Redesigning GitHub Repository Page
#309Earlier quoted context omitted.
Most software in the 90s were highly customizable and a joy to use because of that. I don't remember customization adding a lot of complexity to desktop applications (having worked with classic VB6, VB.NET (WPF) and Qt4). The complexity today comes from the fact that there is much more focus and priority on getting the application to match designers' vision. Its extremely complex to offer the user customization while…
In the 90s, how many updates were there, especially introducing new features? I guess the problem is, if you introduce a new feature in a web app, it can be hidden by the customized design of users. Or it would just appear at a random place in the UI, forcing the user to re customize around that new feature.
Yes that is indeed a problem, but not unsolvable.
Customization usually doesn't mean radically changing things. Its more about moving UI elements around or changing a List into a Grid etc. A combination of "new" highlight with a "Whats New" popup (extra points for short video intro) usually does the trick.
Re: Redesigning GitHub Repository Page
#310Earlier quoted context omitted.
As a developer, the README is useless, I am usually on a Github repo to start looking at code, and I don't want to have to first scroll through a README. IMHO documentation websites and the like is where people should get their first feeling for a project, that is where the README should be.
Hilariously I feel the exact opposite. I'll use OctoTree if I want to view the code, as github's code view is absolutely horrendous. It's like when your using Mac's Finder, it doesn't make any sense. I visit the main page of a repo to see the Readme or to go straight to the issues/prs page. I'll use OctoTree to view code.
Using Github's tool for looking at the code tree is mainly so that I can grab a link and point someone to a line in a file.