7 ms·

> 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

> 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 development tools. That other people don't grasp them is not relevant for GitHub. Also, the three most common navigation tasks I do are "go to the code", "go to the issues" and "go to the pull requests." Those are also the first three tabs at the top of the hierarchy. I don't think that's an accident; I think the designers at GitHub designed the layout so that the most common tasks are on top and first. In other words, they designed GitHub like a tool, not a normal webpage. With this redesign, I'm going to constantly have to find the "Issues" and "Pull Requests" tabs among a sea of others. That's not good usability. I've thought that maybe the markdownified README should be flipped up on top, but even that I think is counter-productive. 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. But READMEs can be quite long (which is a good thing), and it would sometimes be a pain to always scroll past them to get to the files. The better solution for that is a good project page.

grblovrflowerrr 8y ago
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.
- jdmichal 8y ago
  The only thing I've ever seen actually work is a desktop environment. I did a proof of concept for the Coast Guard using Ozone [0]. It basically acts like a desktop, where widgets are individual frames that act like windows with cross-communication ability. But even then, internal configuration of widgets is the same problem as before, just scope-limited... [0] https://github.com/ozoneplatform/owf-framework/wiki https://github.com/ozoneplatform/owf-framework/wiki
- tedunangst 8y ago
  GitHub should go full MySpace, completely custom css per project.
  - drusepth 8y ago
    Considering: 1) Most GitHub users are more tech-savvy (and often more CSS-savvy) than your average MySpace users, and 2) Most GitHub users put a lot of value in their repo pages, this actually seems like it wouldn't _inherently_ be the worst idea, assuming the proper precautions were in place versus bad actors. Allowing each org to fully customize their git repo almost encroaches upon (or replaces?) project websites, which already has some overlap with README files (which aren't currently prioritized). Kill two birds with one stone by giving developers what to prioritize on their repos?
    - tharax 8y ago
      > 2) Most GitHub users put a lot of value in their repo pages, I think you underestimate how many "Single commit, push and forget" test repositories are out there.
    - oblio 8y ago
      3) Most developers are absolutely awful graphic designers.
    - johannes1234321 8y ago
      There is lots of value for me in the fact that all those project pages look alike. I can easily go to any project and immediately know where to look and click. This is useful for doing technical evaluation of projects. On Myspace the goal was to show individuality and creativity. GitHub is about the code.
Forge36 8y ago
I think the author describes the problem with the redesign the best: its noisy. Your point over how hierarchy helps programmers use GitHub feels lost on the designer. It feels as if they're designing for a different user.
- rob_b 8y ago
  That noise is the exact reason why I think the design over the years hasn’t strayed away as captured in the screenshots. One of my favorite parts of using GitHub is that the design is clean and easy to navigate. Throwing twenty widgets on there and cramming everything on top of each other adds clutter and distracts users from being able to visually navigate the page. I can’t speak for everyone, but given the chance, I prefer using GitHub over BitBucket and GitLab because the design is much cleaner and easier to navigate.
  - jlarocco 8y ago
    Strongly agree with this, and it's probably the biggest reason I don't use BitBucket unless I'm getting paid to. The other big reason is that Bitbucket loads bunch of trackers and JavaScript from remote servers.
    - throwaway77790 8y ago
      Names/urls of the trackers and scripts?
      - jlarocco 8y ago
        I block the requests to google-analytics.com, newrelic.com, and statuspage.io. I allow the requests to atlassian.com, cloudfront.net, "bytebucket.org", and bitbucket.org. For comparison GitHub connects to github.com, githubusercontent, githubassets.com, and githubapp.com. I am blocking the githubapp.com requests, though. And finally sourcehut doesn't make any requests outside of sr.ht
  - clenneville 8y ago
octobanana 8y ago
> 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 collapsed by default, but the click through rate was quite low, so the expanded view became the default. [0] https://octobanana.com/software/fltrdr https://octobanana.com/software/fltrdr
- tedunangst 8y ago
  Is the front end itself available?
  - octobanana 8y ago
    It's all server-side rendered. I've been considering open sourcing the site, but there's some cleaning up to be done first.
- cbsks 8y ago
  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.
  - octobanana 8y ago
    > 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.
    - 8y ago
shaki-dora 8y ago
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.
- dc_gregory 8y ago
  However, a lions share of the revenue for github will be from developers, rather than "consumers".
  - shaki-dora 8y ago
    The point was that developers themselves are often browsing repositories they do not own/contribute to.
    - swish_bob 8y ago
      And what is it those developers are doing? Personally, I'm reading the README and/or looking at the contents of files. Plus looking at issues. Very rarely am I looking for the releases tab. I'm amused that people are using the "I only do this every 6 months so I can't remember where it is" argument. If you only need the functionality every 6 months, perhaps not having it in your face every time you use it might be a good thing ...
      - oneeyedpigeon 8y ago
        Isn't the point that everything should be easy to get to (even if you’ve never been to releases, it should be obvious how to get there) but frequently-accessed things should require less effort?
vanderZwan 8y ago
> Also, the three most common navigation tasks I do are "go to the code", "go to the issues" and "go to the pull requests." (...) With this redesign, I'm going to constantly have to find the "Issues" and "Pull Requests" tabs among a sea of others. That's not good usability. I agree with this point, but it is one with a very easy fix: make them the first three tabs after "Overview" in the redesign.
klmr 8y ago
I’m a big fan of nested hierarchies. But hierarchies only work when they are logical. And on GitHub they patently aren’t: For instance, I’ve got to search for the Releases tab every single time. Its placement below “Code” makes no sense whatsoever. And even though I know this, I’m still disorientated every time. The same is true for some of the other tabs. I agree with you about the Issues and PR tabs, but I think it’s still a better solution to flatten the hierarchy and simply pull these two tabs to the left, directly after “Code”.
- izietto 8y ago
  I agree, but that's another point: maybe hierarchies could just be "refactored", e.g. letting Releases be a top tab item
- scott_s 8y ago
  As commenters point out in sibling threads, there is a logic to the hierarchy: the top is GitHub operations and concepts, while the bottom are git concepts. (“Releases” are really just tags.)
  - dwild 8y ago
    Releases aren't just tags, they have files and descriptions, it's a whole new things that Github offer. Tags are available through the branch dropdown (this is where I get them when I need them) and they do have a tabs for it in Release (I do see even more so what the article was talking about with the confusion that hierarchy bring), but when I go to the Release page, it's to get an officially packaged release, nothing else.
Grue3 8y ago
>Also, the three most common navigation tasks I do are "go to the code", "go to the issues" and "go to the pull requests." Well, I don't get any pull requests, so my most common navigation tasks are "go to the code" and "go to the releases" and maybe "go to the issues". Now there's an obvious problem: "go to releases" is in a completely different place than everything else! And since I release only once about 6 months, I always spend a lot of time trying to find the releases tab. That is not good usability. There's no reason for "releases" to be a sub-tab under code, since "releases" also hosts binary artifacts that are not in the repo.
cpsempek 8y ago
This is a great point. The author completely disregards the fact that this is a tool, and a battle tested one at that. Moreover, GitHub has presumably done a lot of testing and analysis on how people use and navigate their site. The fact that author disregards this fact (or, likely possibility) shows a stark lack of understanding in the product side of design. Don't get me wrong, design and it's principles are important and I appreciate pretty stuff as much as the next user. But use those to inform your new products or features, don't assume that "bad" design is the result of poor design choices, but actually smart product decisions by a team with a good understanding of how users actually use the tool. Maybe I'm giving too much credence to GitHub's product team, but the author gave none so I figured I'd toss a vote of confidence their way.
HeavyStorm 8y ago
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.
mmiller42 8y ago
I didn't like the body of content above the readme as well, and you got me thinking about the positioning. I was thinking maybe the "Overview" section of the page could be collapsible. By default, it's expanded, whenever you navigate to the repo from GitHub or direct URL. But since many links to GitHub are appended with "#readme" (for example, some package managers like npm/yarn autofill the package URL to be the GitHub repo + #/readme when generating the manifest files), instead of sending the user halfway down the page with an anchor, it could default to having the toolbar collapsed instead. I think that would be especially better in mobile.

grblovrflowerrr 8y ago

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.

jdmichal 8y ago
The only thing I've ever seen actually work is a desktop environment. I did a proof of concept for the Coast Guard using Ozone [0]. It basically acts like a desktop, where widgets are individual frames that act like windows with cross-communication ability. But even then, internal configuration of widgets is the same problem as before, just scope-limited... [0] https://github.com/ozoneplatform/owf-framework/wiki https://github.com/ozoneplatform/owf-framework/wiki
tedunangst 8y ago
GitHub should go full MySpace, completely custom css per project.
- drusepth 8y ago
  Considering: 1) Most GitHub users are more tech-savvy (and often more CSS-savvy) than your average MySpace users, and 2) Most GitHub users put a lot of value in their repo pages, this actually seems like it wouldn't _inherently_ be the worst idea, assuming the proper precautions were in place versus bad actors. Allowing each org to fully customize their git repo almost encroaches upon (or replaces?) project websites, which already has some overlap with README files (which aren't currently prioritized). Kill two birds with one stone by giving developers what to prioritize on their repos?
  - tharax 8y ago
    > 2) Most GitHub users put a lot of value in their repo pages, I think you underestimate how many "Single commit, push and forget" test repositories are out there.
  - oblio 8y ago
    3) Most developers are absolutely awful graphic designers.
  - johannes1234321 8y ago
    There is lots of value for me in the fact that all those project pages look alike. I can easily go to any project and immediately know where to look and click. This is useful for doing technical evaluation of projects. On Myspace the goal was to show individuality and creativity. GitHub is about the code.

Forge36 8y ago

I think the author describes the problem with the redesign the best: its noisy. Your point over how hierarchy helps programmers use GitHub feels lost on the designer. It feels as if they're designing for a different user.

rob_b 8y ago
That noise is the exact reason why I think the design over the years hasn’t strayed away as captured in the screenshots. One of my favorite parts of using GitHub is that the design is clean and easy to navigate. Throwing twenty widgets on there and cramming everything on top of each other adds clutter and distracts users from being able to visually navigate the page. I can’t speak for everyone, but given the chance, I prefer using GitHub over BitBucket and GitLab because the design is much cleaner and easier to navigate.
- jlarocco 8y ago
  Strongly agree with this, and it's probably the biggest reason I don't use BitBucket unless I'm getting paid to. The other big reason is that Bitbucket loads bunch of trackers and JavaScript from remote servers.
  - throwaway77790 8y ago
    Names/urls of the trackers and scripts?
    - jlarocco 8y ago
      I block the requests to google-analytics.com, newrelic.com, and statuspage.io. I allow the requests to atlassian.com, cloudfront.net, "bytebucket.org", and bitbucket.org. For comparison GitHub connects to github.com, githubusercontent, githubassets.com, and githubapp.com. I am blocking the githubapp.com requests, though. And finally sourcehut doesn't make any requests outside of sr.ht
- clenneville 8y ago

octobanana 8y ago

> 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 collapsed by default, but the click through rate was quite low, so the expanded view became the default. [0] https://octobanana.com/software/fltrdr https://octobanana.com/software/fltrdr

tedunangst 8y ago
Is the front end itself available?
- octobanana 8y ago
  It's all server-side rendered. I've been considering open sourcing the site, but there's some cleaning up to be done first.
cbsks 8y ago
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.
- octobanana 8y ago
  > 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.
  - 8y ago

shaki-dora 8y ago

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.

dc_gregory 8y ago
However, a lions share of the revenue for github will be from developers, rather than "consumers".
- shaki-dora 8y ago
  The point was that developers themselves are often browsing repositories they do not own/contribute to.
  - swish_bob 8y ago
    And what is it those developers are doing? Personally, I'm reading the README and/or looking at the contents of files. Plus looking at issues. Very rarely am I looking for the releases tab. I'm amused that people are using the "I only do this every 6 months so I can't remember where it is" argument. If you only need the functionality every 6 months, perhaps not having it in your face every time you use it might be a good thing ...
    - oneeyedpigeon 8y ago
      Isn't the point that everything should be easy to get to (even if you’ve never been to releases, it should be obvious how to get there) but frequently-accessed things should require less effort?

vanderZwan 8y ago

> Also, the three most common navigation tasks I do are "go to the code", "go to the issues" and "go to the pull requests." (...) With this redesign, I'm going to constantly have to find the "Issues" and "Pull Requests" tabs among a sea of others. That's not good usability. I agree with this point, but it is one with a very easy fix: make them the first three tabs after "Overview" in the redesign.

klmr 8y ago

I’m a big fan of nested hierarchies. But hierarchies only work when they are logical. And on GitHub they patently aren’t: For instance, I’ve got to search for the Releases tab every single time. Its placement below “Code” makes no sense whatsoever. And even though I know this, I’m still disorientated every time. The same is true for some of the other tabs. I agree with you about the Issues and PR tabs, but I think it’s still a better solution to flatten the hierarchy and simply pull these two tabs to the left, directly after “Code”.

izietto 8y ago
I agree, but that's another point: maybe hierarchies could just be "refactored", e.g. letting Releases be a top tab item
scott_s 8y ago
As commenters point out in sibling threads, there is a logic to the hierarchy: the top is GitHub operations and concepts, while the bottom are git concepts. (“Releases” are really just tags.)
- dwild 8y ago
  Releases aren't just tags, they have files and descriptions, it's a whole new things that Github offer. Tags are available through the branch dropdown (this is where I get them when I need them) and they do have a tabs for it in Release (I do see even more so what the article was talking about with the confusion that hierarchy bring), but when I go to the Release page, it's to get an officially packaged release, nothing else.

Grue3 8y ago

>Also, the three most common navigation tasks I do are "go to the code", "go to the issues" and "go to the pull requests." Well, I don't get any pull requests, so my most common navigation tasks are "go to the code" and "go to the releases" and maybe "go to the issues". Now there's an obvious problem: "go to releases" is in a completely different place than everything else! And since I release only once about 6 months, I always spend a lot of time trying to find the releases tab. That is not good usability. There's no reason for "releases" to be a sub-tab under code, since "releases" also hosts binary artifacts that are not in the repo.

cpsempek 8y ago

This is a great point. The author completely disregards the fact that this is a tool, and a battle tested one at that. Moreover, GitHub has presumably done a lot of testing and analysis on how people use and navigate their site. The fact that author disregards this fact (or, likely possibility) shows a stark lack of understanding in the product side of design. Don't get me wrong, design and it's principles are important and I appreciate pretty stuff as much as the next user. But use those to inform your new products or features, don't assume that "bad" design is the result of poor design choices, but actually smart product decisions by a team with a good understanding of how users actually use the tool. Maybe I'm giving too much credence to GitHub's product team, but the author gave none so I figured I'd toss a vote of confidence their way.

HeavyStorm 8y ago

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.

mmiller42 8y ago

I didn't like the body of content above the readme as well, and you got me thinking about the positioning. I was thinking maybe the "Overview" section of the page could be collapsible. By default, it's expanded, whenever you navigate to the repo from GitHub or direct URL. But since many links to GitHub are appended with "#readme" (for example, some package managers like npm/yarn autofill the package URL to be the GitHub repo + #/readme when generating the manifest files), instead of sending the user halfway down the page with an anchor, it could default to having the toolbar collapsed instead. I think that would be especially better in mobile.