Filter by label (Repo Issue List)

[Huddie]

Currently you cannot tap labels in the repoIssueSectionList but can once you tap into a specific issue (it will redirect you)

When tapping on a label in Repo Issue List:
I think we should just add is:”(label-name)” to the search so that it filters by that label

When tapping on a label inside a specific issue:
We should open the repo issue list in app and again append is:”(label-name)”

_{Sent with GitHawk}

[rnystrom]

Go for it!

[BrianLitwin]

makes sense @Huddie. I use the label tapping feature a lot on GitHub web to look for "help wanted" issues. Are you taking this? I'd be happy to work on it if you're not.

[Huddie]

@BrianLitwin I’m a bit busy with school these next few days so I won’t be able to get to it. If you want to knock it out that would be awesome!

_{Sent with GitHawk}

[BrianLitwin]

From Issue:

 

From deeper in view controller stack:

 

[Huddie]

@BrianLitwin

1. Looks awesome
2. This also works on the repoIssueSectionController?

_{Sent with GitHawk}

[BrianLitwin]

This also works on the repoIssueSectionController?

@Huddie I'm going to PR this w/o that feature -> These labels are nested pretty deep in views and I want to make sure the communication patterns I'm using meet expectations first. Then adding that in will be easier.

[Huddie]

@BrianLitwin @rnystrom I think clicking labels in repoIssueSectionController is the essential one just because that's where users are searching for issues and would want to to filter that search. Less likely someone will be nested deep somewhere are want to search by the label.
I know at first I suggested we redirect to search when clicking a label outside the repoIssueSectionController but I think we should keep with Github practice on this one:

Inside repoIssueSectionController -> Adds label:xxxxx to the search bar
Anywhere else -> Shows label description or if one is not provided shows the label name.

I'll touch on the "Anywhere else" one. If you're on github and hover over a label, it has a hover-over view that says the label name. Only when inside of the issue tab, when searching for issues, does it append to the search.
I don't think redirecting people when they click labels (especially when deep) is a good idea. Could be annoying if you do it by accident

Thoughts?

[BrianLitwin]

I don't think redirecting people when they click labels (especially when deep) is a good idea. Could be annoying if you do it by accident

we're already re-directing them to a web view search, so just trying to substitute that with an in-app search. I agree that there is a lot of 'clickable' surface area on the UI and it's important not to annoy users.

Also agree that users might want/expect the labelPressed -> search Issues functionality to happen in the initial issues view controller, I don't mind PR'ing that functionality instead.

[j-f1]

How about pushing a new search controller when tapping on the label instead of popping back to the closest such controller? Combined with the ability to tap labels in the search results, this would better match GitHub’s behavior.

[Huddie]

🤷‍♂️ my suggestion would still be only the search vc has a clickable label and the others just show the label description or name. I think pushing may make more sense than popping but pushing could lead to a stack full of search vc's and issues vc's unless I'm understanding it wrong.

[j-f1]

IMO that stack is expected since that’s how the browser version behaves. You can hit “back” multiple times to get back to the notifications, or the UI could be changed so the tab bar is always visible and users could click on the appropriate icon to get back to notifications.

[Huddie]

The browser though has certain traits that makes they reasonable. The main one being how do you get back out of the stack and back to the main app. Like you suggested we could move the tabbar to overlay. Seems like a bigger change that @rnystrom should weigh in on

_{Sent with GitHawk}