4 ms·

I really like this. One of the changes not mentioned in the article was merging the file path into the repo name at the top. Since the file path ALWAYS starts w

I really like this. One of the changes not mentioned in the article was merging the file path into the repo name at the top. Since the file path ALWAYS starts with the repo name anyway, this makes a lot of sense and eliminates redundancy. It's a shame he didn't add the language colour bar into the final comparison screenshot. I thought that was one of the best changes. It's quite jarring where it is right now. edit: The one issue with this redesign is it clearly goes against a philosophy which GitHub has recently embraced: quickly seeing the status/overview of a repo. Moving the Commits, Branches, Tags, and Contributors from up top to the right sidebar definitely reduces some clutter, but it makes them much less of a focus. And I'm pretty sure this is something GitHub wouldn't want.

ianstormtaylor 13y ago
Wow good call don't know how I forgot that! Added it in now. That was one of my favorite simplifications :) I seriously love finding abstractions like that. Regarding the "seeing the status/overview of a repo" I completely understand, and I think it's a genius way forward for GitHub. I touched on that towards the end with the user-uploaded backgrounds. But basically, I left my version of the refactor at the stage right before adding in the repository's identity. After refactoring away all of the distracting elements, there's much more room to play with creating a really solid identity concept for repositories, instead of the hacked together one we see today.
masklinn 13y ago
As TFAA hints, the Branches and Tags counts don't provide any useful information, they're highly dependent on the author's coding and usage style and are orthogonal to any interesting information about both the repository itself and user engagement with the repository. Consider: Django has 38 branches and 41 tags, Rails has 25 branches and 183 tags, Symphony has 6 branches and 44 tags, Play has 4 branches and 48 tags, Flask has 15 branches and 16 tags. What did that tell you about them? Nothing. > It's a shame he didn't add the language colour bar into the final comparison screenshot. I thought that was one of the best changes. I thought not including it was an excellent choice: aside from providing a jarring dash of colour it is a complete waste of space, if you interact with the repository you probably know which language(s) it is coded in, and if you don't you probably don't care.
- jbranchaud 13y ago
  > and if you don't you probably don't care. The languages used are often one of the first things I am interested in when investigating a new project.
  - masklinn 13y ago
    Why?
    - andrewflnr 13y ago
      Language is an important factor in how hard the project will be to run/build, modify or otherwise actually work with. If it's a library for a language I don't use, I'd like to know that pretty quickly.
      - masklinn 13y ago
        That's probably spelled out or trivial to infer from the readme (or file structure, top-level metadata & packaging files are generally obvious). Knowing pretty quickly I get, but the current prominent (most so for some languages with bright red-ish colors) bar takin the whole width of the screen is way over the top.
- butterflyhug 13y ago
  > if you interact with the repository you probably know which language(s) it is coded in, and if you don't you probably don't care. I don't care about language per se, but I do care about managing the operational complexity of our stack. The programming language is a relevant factor on that score. A project in a new language may require new staff expertise, a new interpreter, a relatively high number of new dependencies, a relatively high investment in new monitoring systems, etc. That said, I don't like the language color bar so far, because I'm having trouble confidently identifying which color is which language. For example: the reddish/orangish color space has JavaScript, Ruby, and the various JVM languages. The appearance of these various reds and oranges frequently shifts due to f.lux and differences between the three monitors I commonly use at work and home. Maybe I'll learn the colors better as I get used to the new repository format, but then maybe I won't. In practice, I look first at the project description and the beginning of the README to see how the project describes its own strengths and weaknesses. Many projects describe their major language choices and runtime requirements as a part of that description, so I never look at the language color bar unless I need to.

ianstormtaylor 13y ago

Wow good call don't know how I forgot that! Added it in now. That was one of my favorite simplifications :) I seriously love finding abstractions like that. Regarding the "seeing the status/overview of a repo" I completely understand, and I think it's a genius way forward for GitHub. I touched on that towards the end with the user-uploaded backgrounds. But basically, I left my version of the refactor at the stage right before adding in the repository's identity. After refactoring away all of the distracting elements, there's much more room to play with creating a really solid identity concept for repositories, instead of the hacked together one we see today.

masklinn 13y ago

As TFAA hints, the Branches and Tags counts don't provide any useful information, they're highly dependent on the author's coding and usage style and are orthogonal to any interesting information about both the repository itself and user engagement with the repository. Consider: Django has 38 branches and 41 tags, Rails has 25 branches and 183 tags, Symphony has 6 branches and 44 tags, Play has 4 branches and 48 tags, Flask has 15 branches and 16 tags. What did that tell you about them? Nothing. > It's a shame he didn't add the language colour bar into the final comparison screenshot. I thought that was one of the best changes. I thought not including it was an excellent choice: aside from providing a jarring dash of colour it is a complete waste of space, if you interact with the repository you probably know which language(s) it is coded in, and if you don't you probably don't care.

jbranchaud 13y ago
> and if you don't you probably don't care. The languages used are often one of the first things I am interested in when investigating a new project.
- masklinn 13y ago
  Why?
  - andrewflnr 13y ago
    Language is an important factor in how hard the project will be to run/build, modify or otherwise actually work with. If it's a library for a language I don't use, I'd like to know that pretty quickly.
    - masklinn 13y ago
      That's probably spelled out or trivial to infer from the readme (or file structure, top-level metadata & packaging files are generally obvious). Knowing pretty quickly I get, but the current prominent (most so for some languages with bright red-ish colors) bar takin the whole width of the screen is way over the top.
butterflyhug 13y ago
> if you interact with the repository you probably know which language(s) it is coded in, and if you don't you probably don't care. I don't care about language per se, but I do care about managing the operational complexity of our stack. The programming language is a relevant factor on that score. A project in a new language may require new staff expertise, a new interpreter, a relatively high number of new dependencies, a relatively high investment in new monitoring systems, etc. That said, I don't like the language color bar so far, because I'm having trouble confidently identifying which color is which language. For example: the reddish/orangish color space has JavaScript, Ruby, and the various JVM languages. The appearance of these various reds and oranges frequently shifts due to f.lux and differences between the three monitors I commonly use at work and home. Maybe I'll learn the colors better as I get used to the new repository format, but then maybe I won't. In practice, I look first at the project description and the beginning of the README to see how the project describes its own strengths and weaknesses. Many projects describe their major language choices and runtime requirements as a part of that description, so I never look at the language color bar unless I need to.