Repositories are difficult to find, navigate, and differentiate

[billygriffin]

Please describe the problem you think should be solved

We've seen many issues suggesting to change the way we either visualize or group repositories in GitHub Desktop. Right now we just organize repos alphabetically and it's tricky to differentiate many of them visually because it's just in the format of [repo name], which doesn't account for a variety of different scenarios. We have a tooltip that displays on hover, but it's relatively undiscoverable, slow to appear, and requires you to look at each repo individually to differentiate. We also group repos that are on GitHub.com separate from those that are purely local or on another remote. We do have filtering repos via a text input in place today, which should be helpful, but obviously not sufficient based on the feedback.

There have many different implementations suggested, so I wanted to try organize most of the issues I could find in one place to attempt to get our arms around the problem areas as we try to determine a path forward. Ideally, whatever we implement would be something we could work forward from and we could therefore close and/or remove future proposal from all the previous issues.

Relevant issues:

Group repos by organization and show full repo name: #1533
Ability to "pin" repos to top of list: #2038
Allow repo list to be always expanded: #1593
Group repos by organization (and make orgs collapsable): #2037
Add categories for repos to be grouped together: #4945
Add folders for repos to be grouped together: #1598
Group or filter repos by Topics: #4958
Drag and drop and/or add labels to repos: #2324
Add visual differentiation for repos: #1929
Add a keyword to repos in Desktop: #4940
Add placeholder name for repos in Desktop: #3197
Support multiple windows: #3606
Don't persist repo filter after selecting one: #4273
Filter across multiple repos with OR operator: #5280
Repo order is not maintained alphabetically after filtering: #4184
Keep changed repo (local changes) at top: #10946
Filter based on status: #19369

Slight variation
Some way to visually distinguish worktrees: #5764

Additional contextual things:
Which repos have unpushed changes without having to go through the whole list: #7053

Potential problems on ordering/grouping:

1. I want to access the same [x] repos frequently, and navigating to them is unnecessarily time-consuming.
2. When I'm a member of many organizations, I'm only interested in repos for a particular org at a time and having them intermixed and always visible makes it hard to find the ones I care about.
3. Similar to 2 above, filtering only filters on the repo name, but if I want to see the repos in a particular org, for example, there's no way to accomplish that.
4. My mental model of organizing my repos doesn't fit nicely into alphabetical / by GitHub org / other out of the box way of grouping them together.
5. I can't always remember the name of the repo I'm looking for exactly for filtering to work.

Potential problems related to visualizing:

1. If I have the same repo cloned in multiple locations locally, there's no way to visually differentiate between them without the tooltip, which is slow to appear and undiscoverable.
2. I sometimes can't remember what each repo is actually for just by the name, and it would be helpful to have some metadata to trigger my memory.
3. If repos have the same name but are under different orgs, there's no way to differentiate between them except with the tooltip (see 1 above).

Additional considerations

1. We should account for forks
2. Not all repos are pushed up to GitHub - ensure we account for that
3. Org names and repo names are often long and this should account for that
4. Worktrees also share the same problems of visually distinguishing them (see: Add link to usage data page #5674)

I'm sure I didn't capture everything here, so please feel free to suggest edits to this, and feedback is absolutely welcome.

cc: @desktop/design @desktop/support @nerdneha @adamreisnz

[elliotcm]

Thanks @billygriffin.

All of the above are useful suggestions. It feels to me like the crux is not necessarily a difficulty in finding something per se (though that's the case for some things), but for me it's about cognitive load.

Out of all the repos in the world we're already filtered down to the ones that we work on enough to have bothered to import them into Desktop, so we just need a few tools to speed up the last bit of sorting and filtering to get us from dozens down to 1.

That's why most of the features you have here are sorting (most recent, most frequent, pinned repos) or filtering (various kinds of collapsible groups act as filters). You mention that the list currently has filtering but really it has searching, which is a different sort of task.

[adamreisnz]

Thanks for putting this together @billygriffin , I think it's a good summary of the problems/considerations.

Maybe a good idea to also try and list some of the suggested possible ways of addressing these problem, and see which ones are plausible and make the most sense.

I'll start off by listing a few off the top of my head, with potential pros and cons that come to mind.

Display organisation name in front of the repo name in a muted colour

Pros

• Simple and tidy solution
• Organisations are already an established way of organising repo's
• Quick visual identification of repo possible, provided organisation name is meaningful

Cons

• Organisation name can be long
• Repository may be non-github and not have an identifiable organisation name
• Doesn't help people much who have large organisations with many repo's

Display the parent folder name in front of the repo name in a muted colour

Pros

• More control over what's shown than displaying the often static organisation name
• Quick visual identification of repo possible, provided folder name is meaningful

Cons

• There may be no parent folder
• Folder name may me meaningless and just add noise
• Forces people to organise their folders well

Filter repo list by organisation

Pros

• All organisation repo's visible at the same time
• Focus only on the org you're working with/on at that time
• Relatively low effort to implement, as the current search filter could be adapted to also match organisation name

Cons

• Repository may be non-github and not have an identifiable organisation name
• Doesn't help people much who have large organisations with many repo's
• Adding another filter dropdown to the repo list may clutter the UI

Custom grouping of repo's in virtual folders/groups

Pros

• The most flexibility to organise repo's as you see fit
• Doesn't matter if a repo is Github hosted or elsewhere
• Works also when a repo doesn't have an organisation or parent folder

Cons

• Doesn't offer users a point to start with
• Requires the user to pro-actively maintain and organise repo grouping by hand
• Filtering/search may still need to be adjusted to account for groups
• Larger effort to implement

Pinned/favourite repo's

Pros

• Simple, light-weight solution
• Probably sufficient for a large number of users
• Quickly have the repo's you work with the most at the top of the list, without needing to filter/search in addition
• Doesn't matter if a repo is Github hosted or elsewhere
• Works also when a repo doesn't have an organisation or parent folder

Cons

• Only useful if the number of repo's you work on at any given moment in time is limited
• Still doesn't differentiate repo's if they share the same name
• Doesn't address the problem of not remembering/knowing what a repo is by name (although if you've pinned it, you can be assumed to know what repo it is)

Add keywords to repo's

Pros

• Can add multiple keywords for multi-dimensional organising
• Flexibility to organise repo's as you see fit
• Doesn't matter if a repo is Github hosted or elsewhere
• Works also when a repo doesn't have an organisation or parent folder

Cons

• You may forget the keywords
• Still doesn't differentiate repo's if they share the same name
• Will need to adjust the search filter to also match keywords, which could sometimes result in false positives (e.g. if a repo name partially matches a keyword)

Combination of grouping by organisation/folder/custom label

E.g. group by organisation by default, display in front of repo name. Fall back to parent folder name if not present or non-github. Allow to manually edit the label by clicking on it.

Pros

• Organisations are already an established way of organising repo's
• Quick visual identification of repo possible
• Fall back to parent folder name if no organisation available
• Allows manual override for further customisation

Cons

• Will need to store manually assigned labels somewhere
• More development effort

[say25]

Just something to add from my personal experience. I personally manage two copies of the same repo because the project is rather large and sometimes running two copies of the same project for debugging purposes is nice.

[felga]

For me just being able to set a alias to the repo will be enough. I can put numbers or anything I want in the begining to group and continue to use the current ordering.

[ampinsk]

Adding a note on analytics from a discussion in Slack:

• The majority of Desktop users have 3 or fewer repos.
• Median is 2 repos, 75th percentile is 5 repos, 90th percentile is 10 repos

As @billygriffin put it:

So for improved repo organization purposes, it seems like we're solving it for maybe around 10-20% of users, where the other 80-90% won't see a big difference.
However, that's not as relevant for visualization of repos, where the absolute number of repos is less important than how they're displayed.

[Janpot]

So for improved repo organization purposes, it seems like we're solving it for maybe around 10-20% of users, where the other 80-90% won't see a big difference.

Is plain user count the right metric here? What if those 10-20% users use the app way more often?

[billygriffin]

@Janpot Oh absolutely, we just wanted to share a metric that helped to color the impact of the first set of problems. Totally agree that it's not the full story, we just wanted to share this to add context to any potential solutions.

[adamreisnz]

For reference, I've about 60 repo's in there, roughly 25 for open source projects, 15 for clients of mine, 10 personal and 10 for our business. I wouldn't have expected that the majority of people have such a small number of repositories.

[xt0rted]

I've got 35 repos right now (cleaned some out last month) and expect to be adding another 10+ over the next month or so. I also use the app every day.

[ampinsk]

Thanks everybody for the extra context! To echo what @billygriffin said, just because in pure numbers the majority have a small amount of repos doesn't mean we aren't interested in working on alleviating the frustration of having many repos. If anything, it makes it clear that we should be careful to not make the experience worse for users who have a few 😄

[StefanoCecere]

Usually pros with many repos need advanced features, that Desktop doesn’t have.. that’s why 90% Desktop users have 3 repos, they are casual users... I (60 repos, like many using git daily for everything ) would use Desktop as “non advanced client” only if it had some groupings, like discussed here.. so it is a must feature to attract advanced users

[billygriffin]

We're working through some initial design possibilities here, and we'd love to understand a bit more about how people who do have a lot of repos in Desktop are using it. Would any of y'all who are feeling the need for this (and have more than ~20 repos in Desktop) be willing to hop on a video chat with us for an informal user interview and maybe demonstrate to us an example of the ways you're using the app and how it's falling down for you at present?

If you are willing, please react to this message and fill out this user research form (so I know who to email to set it up): https://goo.gl/forms/PG0uBW3TSfsty8uk2

Thanks!

cc: @adamreisnz @xt0rted @Janpot

[adamreisnz]

Done!

[Janpot]

Sure

[kuro68k]

• The majority of Desktop users have 3 or fewer repos.
• Median is 2 repos, 75th percentile is 5 repos, 90th percentile is 10 repos
  Github Desktop version 1.0.12 Authentication Failed during fetch with remote #3816

Is that because they only want 5 repos, or because organizing more than 5 becomes a real pain?

I have had 40+ repos at work for various projects because I had to, and anything that encourages people to use more repos instead of single giant repos has to be a good thing.

[kuro68k]

Tagging is effective and flexible. With the ability to "pin" tags the user could create their own custom views, as well as quickly doing tag searches when required. Tags are somewhat preferable to folders because a project can have as many tags as needed, where as generally it can only be in one folder.

Ideally the tags would sync with Github so that the same search/filtering options are available via the web and to all members of an org.

Personally I preferred the old UI where there was a list down the left hand side with a search box. Fast access is important when you have many repos and switch often.

[adamreisnz]

@kuro68k

Personally I preferred the old UI where there was a list down the left hand side with a search box. Fast access is important when you have many repos and switch often.

I also missed the sidebar originally, but you can bring it up with CMD-T now, and the search box gets focus automatically, so it's pretty quick still to access the sidebar once you get used to it.

[DorothyLindman]

When you decide on the UX around this issue, please remember to add something into the documentation or help files explaining what the grouping scheme is, what the icons mean, etc. In about 15 minutes of searching, I haven't found anything that explains this.

(Is there any maintained documentation on how to read the UI? I wrote a brief intro several months ago, but it's already out of date, and I haven't found the necessary docs to update it.)

[kuro68k]

It seems like some of the tagging could be automatic, e.g. language used.

I was in a company with hundreds of repos, initially organized in a hierarchy. We found that tags were a much better solution.

[billygriffin]

Thanks for the perspective folks - we're working through a few other things and still digesting this so sorry for the delay, but this is all helpful context and we appreciate it.

In about 15 minutes of searching, I haven't found anything that explains this.

Hi @DorothyLindman! I'm curious what specifically you're referring to. Do you mean related to this issue or more generally in GitHub Desktop? If you'd be willing to chat about that separately, I'd love it if you'd fill out the form reference in this comment and I'll reach out.

[trulysinclair]

I guess I'll add to this. There are a variety of ways the organization can be done.

Virtual folders, groups, etc, are all nice. The organization is a very tedious task, and maintaining it is a pain. I personally recommend a form of multi-layered organization. Anywhere between visual hints to actual rendering changes can be helpful.

Visual Hints

Public vs Private

One of the issues we immediately face is being able to tell one kind of repo from another, this includes public and private. The book and lock icons are all the same color in a tight space, I recommend subtle color changes like giving the lock a slight red tint or something similar.

Clone vs Source vs Fork

This organization can be achieved by dropdown groups.

Organizations

In a tree of repos, we can simply add the org's icon in front of a dropdown with the org's name similar to how users are rendered in commit history, and then let the user decide if it should be alphabetical or orgs-before-repos.

Parent folder

Adding a muted parent folder would help greatly. There should always be a parent, whether its a folder like /var or a drive like C:/. We don't have to hold the user accountable for organizing their folders, it would just give them an idea of where it is in the file system and they may remember what it's for automatically.

I don't think the parent should come before, because variable length names would break uniformity. Instead, the parent should be placed above, below, or to the right of, the repo name, in a smaller font in a muted style.

Description

This one is honestly a helper. Not every repository has a description, and so it should be a conditional render. Descriptions should be placed preferably under the repo name in a smaller, and dimmer (but not muted), style.

[MartinNiederl]

Now more than a year has passed since the last comment.
Are there any updates?

[jil-jeep]

yea

…

On Sat, Sep 26, 2020 at 1:06 PM Martin Niederl ***@***.***> wrote: Now more than a year has passed since the last comment. Are there any updates? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6460 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARAX3N5HWGUJPDH6XQAATZ3SHW4JRANCNFSM4GLNFO3A> .

[JimmyCushnie]

The update is that they closed the issue, and apparently don't think there's a problem anymore.

Github Desktop is so frustrating, everything about it is great except for this ONE giant glaring missing feature.

[cloewen8]

Re-read the problem, and looking at my list of repositories, it is still a problem.
I've had to adapt by avoiding features that would create repositories with similar or identical names (namely wikis and partially branches).

[JimmyCushnie]

I've thought of a solution. If I make a second github account called ___________JimmysPinnedRepos, and I move all my important repos to that account, they will stay at the top of the list.

The only downside is that it would be stupid

[steveward]

@JimmyCushnie I've edited your comment to remove profanity, and it is considered to be a violation of the GitHub Desktop Code of Conduct. You may consider this an official warning.

[kuro68k]

Given that this is closed I think we can take it that there is no intention to improve the app in this aspect. Which is of course fine, it can be a simple app for low end users with only a small number of repositories.

[steveward]

@kuro68k we ask that you please only comment with feedback that is beneficial to GitHub Desktop's community as is mentioned in Our Standards. Please consider this is a warning. If an issue is closed it does not mean that we will not reconsider changing things going forward, it just means it is not something the team is not currently focused on.

[amcgregor]

Difficult to have positive, beneficial feedback on something that is out of our own control to correct and has seemingly been put on ice, and furthermore is now approaching three years in age. Is throwing a screenshot up demonstrating the uselessness of the current arrangement beneficial?

That represents one fifth of the total scrollable area for the repository listing, and is notable in the use of prefix namespacing. (Which can be elided similar to multiple depths of folder inclusion and used for automatic grouping.) It's almost usable as-is, barring the auto refreshing problem, which makes it completely unusable, ref #1128 which I sincerely hope does not end up the way this issue did (edit: never mind, also three years old. I keep forgetting I survived a coma. The time; where did it go?)

⌘T and jumping to a repository by filtering is almost acceptable, but that completely ignores the "design" of that sidebar in favour of Vim-like CtrlP motion. If I want that, I can stay within Vim, CtrlP is good people, and there is extensive and excellent Git integration available for that editor. The only purpose for which I formerly had used GitHub Desktop is now easily accomplishable there, that is, marking subset hunks of a file for commit vs. committing the whole file, and lets me unify project management and manipulation under a single environment. And avoid mouse-based wrist hurt disease while doing so. And utilize pre-commit without failure because it can be actually aware of the Python virtual environment my code is contained within. And can utilize advanced interactive authentication mechanisms (e.g. hardware smartcard) for improved security. And only consume 40MiB of RAM (for a full IDE) instead of 584.9MiB for a web application runtime and client browser environment because Electron. And…

Sorry, my level of flabbergasted is only rising. :'( I learned how to swallow and see and walk again, which took ~6 months, how hard can it be to make a decision and implement improvements to a list of labels? (There have been around six additional half-years of time since.)

[Edit in response to an update to #1128 as of one hour after initially writing this: finally closed, option to +mostly+ disable background fetch added to 2.5.6, so there is, uh, some progress.]

[kuro68k]

@kuro68k please only comment with feedback that is beneficial to GitHub Desktop's community -- consider this is a warning. If an issue is closed it does not mean that we will not reconsider changing things going forward, it just means it is not something the team is not currently focused on.

@steveward I have reported this comment as a COC violation. You might consider revising it. There is no need for this kind of hostility, I was explaining the situation in neutral language in order to de-escalate. Please be aware that it can be difficult to infer tone from text comments so you should usually assume good faith where possible. Unfortunately your comment is unambiguously hostile and unwelcoming.

[steveward]

@kuro68k saying that GitHub Desktop "can be a simple app for low end users with only a small number of repositories" is not helpful feedback and goes against Our Standards, which is why I issued a warning.

I appreciate the feedback and enthusiasm everyone has shared for us to make changes to the repository list, but I am going to lock this issue for the time because the discussion is starting to stray away from that.