Redesigning GitHub Repository Page • Hacker News Board

Re: Redesigning GitHub Repository Page

#291

Post by JoshTriplett » Fri, Mar 01, 2019, 9:36 PM UTC

userbinator wrote: post #117

dcosson wrote: post #77

Earlier quoted context omitted.

I was half onboard with his reasoning to remove the commit messages. But then I realized, they're only useless if they're bad commit messages. Especially if you're using PRs and using "squash + merge" for all your changes (which should really be the default IMO) the commit messages will be the PR titles and PR number and that's pretty useful. And then the commit time for the file is obviously super important. What el…

And then the commit time for the file is obviously super important. What's nice about git is that you also get this propagating to the directories all the way up to the root, so you can quite easily see which areas of the code have been changed recently too. This isn't something normal filesystems have (for performance reasons more than anything --- I imagine if one tried to use git as a filesystem such that each fil…

> What's nice about git is that you also get this propagating to the directories all the way up to the root, so you can quite easily see which areas of the code have been changed recently too.

Exactly! It's easy to see at a glance, for instance, that the code changed recently but the documentation hasn't been updated in a long time. Or that the LICENSE file just got updated a few days ago. Or that a new top-level module got introduced.

Re: Redesigning GitHub Repository Page

#292

Post by jkooda » Fri, Mar 01, 2019, 9:51 PM UTC

Typo on final mockup "New pull Requrest" I like where this is heading, but you'll get pushback from folks on the all-white UI... eye fatigue. Include dark mode and you're good to go!

Re: Redesigning GitHub Repository Page

#293

Post by sireat » Fri, Mar 01, 2019, 11:00 PM UTC

I am still amazed that there is no easy builtin way to sort your repositories by date on Github.

Also, how do I filter all my repositories to be the ones I created from scratch not the ones I forked? EDIT: This one is easy just use Sources Filter(strange name but ok).

With 300+ repos it is getting rather unmanageable.

Sure there is an API for creation date but that is just silly.

Re: Redesigning GitHub Repository Page

#294

Post by HeavyStorm » Fri, Mar 01, 2019, 11:02 PM UTC

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 like hierarchies as an UI metaphor and I agree with you: github is a development tool. Unfortunately, it seems that the author confused his usual ux work with the one he was proposing for github.

That said, hierarchies are dangerous because they hide stuff. It's clear that github's need reviewing.

Re: Redesigning GitHub Repository Page

#295

Post by hvindin » Sat, Mar 02, 2019, 12:07 AM UTC

I was actually pretty pleased with this as a proposal right up until Problem 8

I actually use the description of commit and the time of commit quite regularly to figure out how active a project is.

If everything but the readme and maybe a contrib folder hasn't been updated in 6 years, I have concerns. Unless the commit message on one of those, say the contrib folder, indicates that adjustments have been made because the repo I'm looking at considers its work now be a solved problem space and I can see few/no issues or pull requests then I'm backing right out and looking elsewhere for a project that might address my particular problem.

Replace that information with a commit history that doesn't indicate to me where those commits got made (ie. Was it core code changes? A spelling mistake? Where are people actively working?) and a bunch of stats that I usually don't care all that much about and which are already available if I did really want them. Now the repo landing page becomea a chore to navigate.

However literaly everything up to #8 I actually think makes a lot of sense and is a small enough deviation from what is there that users aren't going to be immediately shocked.

Re: Redesigning GitHub Repository Page

#296

Post by zetabyte » Sat, Mar 02, 2019, 7:13 AM UTC

Frequently used feature as a open source contributer on github. - git fork, clone, pull request. - searching/filing the Issues.

Does this new redesign proposal enhanced the usability of these features? Not at all.

Just my opinion.

Re: Redesigning GitHub Repository Page

#297

Post by contradictioned » Sat, Mar 02, 2019, 8:30 AM UTC

shaan7 wrote: post #201

grblovrflowerrr wrote: post #56

Earlier quoted context omitted.

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

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.

Re: Redesigning GitHub Repository Page

#298

Post by neop1x » Sat, Mar 02, 2019, 11:16 AM UTC

I hate how they present is as "problem" they are trying to "solve". I don't have any of these problems and I use Github almost daily.

Why someone always has to create artificial problems and re-design and re-invent something which don't need any change? And it is not rare that they make things worse from usability standpoint.

A similar example (not layouting though) is also that flat design in iOS. Buttons which have no border and can't be distinguished from labels. Flat, solid colors. If you look at Windows 1.0, it looks nicer than current iOS design, it even has an innovative border around buttons, rounded! So why are designers gong back and making it worse than it had been at the beginning of graphical UI design...

Re: Redesigning GitHub Repository Page

#299

Post by roryokane » Sat, Mar 02, 2019, 11:28 AM UTC

structural wrote: post #82

jbergknoff wrote: post #61

I like a lot of these suggestions. For instance, it's true that I never get anything out of the commit messages in the file browser (though "how recently has this file been updated?" is often useful). One other thing I've never understood about the GitHub UI is why the issues search defaults to open issues. I have literally never wanted to restrict my search in that way. Maybe it's just geared towards maintainers? As…

As a developer/maintainer of projects, the commit messages in the file browser and open issue view are both incredibly useful. There's important metadata about the structure of a project when looking at the last commit of a group of files: do they all change together? They are more tightly coupled to one another if so. If all the files are touched by each commit, then there's an issue with the project's development p…

> Not showing open issues also has the negative UX that people will look to see if their issue already exists in whatever page they land on, and if they don't see it, create a new one.

I think you misunderstand. The parent comment was suggesting showing both open and closed issues in search results, not only closed issues.

Re: Redesigning GitHub Repository Page

#300

Post by roryokane » Sat, Mar 02, 2019, 11:36 AM UTC

rident wrote: post #265

The article says wraps up by stating the design hasn't lost any information but where's the fork count, watch count and other download options? Also, the lack of borders and flattening of button styles does not improve the design. Borders are even more necessary when data density is increased. Buttons, menus and links now have a variety of borders where they were consistent before. The menu is marginally better but t…

> where's the […] other download options?

In the “Get code as” section. You can see it was moved in there when solving Problem 11. It’s true that the fork and watch counts are missing though.