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}

[rnystrom]

IMO this should just push another search VC w/ the new filter and not pop back. That's a little bit of a jarring experience IMO.

If we're worried about having the editable search bar, maybe we add an option to make the search VC searchable or "fixed".

But I'd just start w/ pushing a new search VC.

[BrianLitwin]

@rnystrom to let people tap labels in the repoIssueSectionList (the main RepositoryIssuesVC list), we still want to push a new view controller? That makes sense to me, just double checking.

[Huddie]

@BrianLitwin Why would we push? I think it should just edit the current search.

_{Sent with GitHawk}

[BrianLitwin]

@Huddie You're right, we could do it that way too. Specifically, I was thinking that it would be easier to return to the default state of the RepositoryIssuesVC by pressing back from the Pushed VC, than by editing the search bar. You see what I'm saying? That might not be a great assumption tho.

[Huddie]

🤔 ya it’s tough to nab both the expected result of updating search bar, but also giving a quick way to revert. I still feel that expected behavior of filling in the search rather then pushing a whole new VC makes more sense. Otherwise we are pushing a new vc that’s exactly the same with one difference, the text. 🤷‍♂️. Maybe a clear labels button or something to make removing labels from the search bar quicker ?

_{Sent with GitHawk}

[Huddie]

@BrianLitwin any update on labels in repoIssueVC? Should this issue be closed?

_{Sent with GitHawk}

[BrianLitwin]

@Huddie sorta waiting for @rnystrom to weigh in on pushing a new VC versus editing the search bar in this last case of tapping an issue label in the main RepoIssuesV

[rnystrom]

Oops. @BrianLitwin pushing is probably the simplest to get moving? But if editing in place is easy, that would be cool!

[BrianLitwin]

I want to track an extra detail of this feature, which is trying to give the user some touchDown feedback when they tap a label so that they understand what's happening when the view transitions.. possibly darken the font or dim the background of the IssueLabel?

[j-f1]

How about reducing its alpha?