> 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.
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.
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?
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 still ensuring pixel perfect UIs. (Emphasis on complex, its not impossible).
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.
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.
Yeah, I tend to be not interested in customization, and I believe "general population" UX studies show that most people (not necessarily devs) aren't interested in customization either.
An example of a tool set in a similar space as GH that has prioritized customization are Atlassian Confluence and Jira. How many of us enjoy that software? More than GH?
Customization can't save software that hasn't gotten the UX right in the first place.
I agree with that, JIRA is so monstrously difficult. But this kind of limited configuration might not be so bad. If it's kept selective, some configuration is well-loved by technical users, the vast majority of GitHub's visitors.
I think the default order would be used by anyone who doesn't care to configure it.
In some sub-tab of the User Settings panels, there could be a drag-and-drop sort list (like the one for sorting the "featured repositories" on the profile) to arrange the tabs in a different order, and a button to reset them to default.
Maybe one other setting I would add is "dark mode". The CSS is essentially already written in public Chrome browser extensions to "reskin" GitHub's UI. This is because customizing light/dark modes is gaining in popularity. It's a new macOS trend and in my experience surprisingly common in iOS apps too. Since about 70% developers trend towards dark IDEs, it makes sense to have.
Unlike JIRA, I don't think any of these settings should be at the forefront... you should just have sensible defaults and a way to customize it. GitHub Help articles are well-indexed on Google and anyone who wants to know how to change the color mode or tab order is only going to do it about once, so clicking through menus is a familiar and safer-feeling (as opposed to direct links to private UIs) UX, and it's the same as any other process like adding a SSH key, webhook, or app password.
I do think that GitHub's main user base is increasingly loving their customizability. VS Code and Atom gain a lot of traction for their total customizability and extensibility with plugins. I'm not at all suggesting GitHub go in that direction -- but, GitHub is more of a cloud-based software tool than a website. A little bit of customizability goes a long way with user satisfaction, at least to tech-enthusiastic users.
Just little feature flags would be incredibly handy. For example, default to ignoring whitespace in PR diffs (a feature otherwise only available if you know the URL trick, and can't be saved to user settings like your preferred diff layout).
It's the same amount of customizability as "how many emails do you want to display per page" in Gmail. It's enough personalization to be useful and done officially instead of through hacky, dangerous, frequently-breaking Chrome extensions to work around the things that impede productivity.
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...
Good god no! One of the reasons Facebook won imho is simply because you didn't have to go hunting for core navigation features for every single user's profile page. I do emphatically NOT want that with Github... write a website for your project on ghpages if you want it customized.
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?
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.
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”.
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.)
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.
> 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.
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.
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
Thanks for the feedback on GitLab’s UI density. We’re working to improve the aesthetics and usability of our system, and feedback from the rest of the community helps us do that. If you have specific feedback, please feel free to share more here.
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.
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 ...
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?
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.
> 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.
> 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.
Ah, I misunderstood slightly. I thought you were only talking about the click to expand the tree. If the hits to the files increased, then it makes sense to have it expanded by default.
> I thought you were only talking about the click to expand the tree.
That makes sense. It would have been an interesting stat to compare, but the metrics only come from resource requests, as those pages don't run any scripts.
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.
>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.
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.
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.