Group inbox by repo and additional interactions when viewing all notifications

[gingerbeardman]

I find the current method of having to switch between repos in the inbox quite laborious.

Ideally inbox would be more like the GitHub approach, where I can mark read all notifications from a repo.

Not the best screenshot, as only one repo shown, but all I have at the moment:

Also see:
#1281
#61

Bug Report Dump (Auto-generated)

Version 1.23.0 (1541192331)
Device: iPhone 6s (iOS 12.1)
TestFlight: false

[rnystrom]

I think this has been suggested a bunch before

_{Sent with GitHawk}

[gingerbeardman]

I found the previous two issues listed, but there could be more

[ijm8710]

Browsing the referenced threads it seems the obstacle was pagination. What about keeping the current setup but simply adding two filter columns for unread/all at the top. That way each repo is still separate if you select a specific repo. And you have the ability to view those repos by the two views without the other repos messing with the pagination. Essentially the view all option would move from a filter option to the all tab (this view would not group by repo due to the complexity mentioned). And if you wanted a repo-view, then the other filter options, which are solely repos now, would present two views instead of one.

And perhaps add a badge for open issues per repo on the filter menu when invoking it.

[gingerbeardman]

That sounds like it would be an improvement in some ways.

But if I'm honest the the core of my request is the grouping so that I can "mark all as read" to dismiss all notifications from a repo whilst I am looking at all notifications.

I do this so often on the GitHub website, or through BitBar (GitHub Notifications Plugin) on macOS. Not being able to do it on iOS is a bit of a pain point.

notifications

• grouped by repo
• filter unread, participating, saved for later, all
• filter by repo

for all

• mark as read

per repo

• mark as read

per thread

• mark as read
• save for later
• unsubscribe

[gingerbeardman]

#2413 is sort of related to this?

[ijm8710]

Yeah my point was that since Ryan had stated trouble with pagination when having the repos grouped but intertwined on one screen perhaps have the features you ask for but in diff screens per repo based on your filter. You could still mass edit on a repo basis but you would only either see one repo at a time or all the repos at once but the latter would not be grouped. So it’s filter sorted as opposed to just the sorting which inferred difficulty. I would foresee all the options you mention still there

[gingerbeardman]

I appreciate your summary. That proposition doesn't seem any better to me and would still require laborious switching between repos; the grouping is the key thing here.

[j-f1]

Why not load all the pages of notifications at once?

[gingerbeardman]

Indeed. Maybe I don't use git enough, or maybe I never let my notifications build up, as I can't remember seeing the "load more" on the notifications. Just load them all (and cache them for next time)?

[rnystrom]

@gingerbeardman FYI you can tap the "..." to view notifications in a repo and the check-mark will then mark all notifs for only that repo read.

[gingerbeardman]

Understood, it's the tapping of "..." switching between repos that is the friction I'd like to avoid.

Here's how a dozen notifications look using the GitHub Notifications BitBar plugin (basically a shell script that can put some UI in the menu bar)

I can hold down alt to make any interaction "mark as read"

here's github.com with the same list

and GitHawk

Also notice how few notifications fit on screen in GitHawk! 5.5 items

[rnystrom]

If someone wants to champion design and dev of this have at it!

_{Sent with GitHawk}

[ijm8710]

I do think the point about how many inbox items fit on the screen at a time is a valid item to revisit

[dimirc]

One way to have full control and filter by repo, will be to load all notifications at once, but we’ll need to do multiple reqs to the notification api as the page size is limited to about 100 records per page (if I remember correctly) so in my case that I have 450 notifications, I’ll need 5 reqs to get all of them.

Checking the response sizes from api, in my example 450 notification will be about 2MB

Another way will be to parse the web version html /notifications main list, to just extract the repo names and then using the api, load the paginated results of each repo