Discussion: Issue title in Push Notification

[rjonesy]

Hey team, I opened this as a discussion since I'm sure you considered it and decided against it – just wanted to re-open in case anything has changed. Feel free to move, comment, or close it.

Currently: iOS notifications use all 3 fields.

Title = activity
Sutbtitle = issue number (project/repo/issuenumber
Body = content

Honestly this is pretty damn good, I see why you choose it, and I appreciate you using the Subtitle. My personal issue is that I can't see the Issue title. For example the above title is "Implement Widget Settings with description and video" Of course, if I want to see that I have to give up something else or cram more into the notifications...

I consulted how this was solved on Github web. Here's a reminder:

With that, I think you have a few options that may be better. Allow me to use our issue as an example. Options:

1. Keep everything, cramming activity type into body

weather-line/weather-line-2 #123
Implement Widget Settings with descriptions...
mention: Got this working in SwiftUi rjonesy, but having some problems with iPhone frame overlay.

2. Ditch proj/repo

kcharwood mentioned you in #123
Implement Widget Settings with descriptions...
Got this working in SwiftUi rjonesy, but having some problems with iPhone frame overlay.

Of course there are many many more, but those are my top two. I believe both are shippable, but yall have more context and breadth of the uses here.

[brianlovin]

Could we get all three in, still?

**kcharwood mentioned you**
**weather-line/weather-line-2 #123 Implement Widget ...**
Got this working in SwiftUi rjonesy, but having some problems with iPhone frame overlay.

It will cut off a lot of the issue title, but at least it's peeking in to provide some context. Could that be helpful?

One other option:

**kcharwood mentioned you in weather-line/weather-line-2 #123**
**Implement Widget ...**
Got this working in SwiftUi rjonesy, but having some problems with iPhone frame overlay.

I kind of like your option:

weather-line/weather-line-2 #123
Implement Widget Settings with descriptions...
mention: Got this working in SwiftUi rjonesy, but having some problems with iPhone frame overlay.

But I would just add a tiny bit more context to the body:

weather-line/weather-line-2 #123
Implement Widget Settings with descriptions...
@kcharwood mentioned you: Got this working in SwiftUi rjonesy, but having some problems with iPhone frame overlay...

[brianlovin]

Hmmm @rjonesy your original comment disappeared, did you have second thoughts?

[rjonesy]

@brianlovin Besides the original post I have not commented yet, dunno what you saw – I blame the Github desktop team, not mobile, of course. 😈

I agree this one (your last one) is the best. And it can scale to Push Notifications when Issues are closed or merged, when y'all get there.

weather-line/weather-line-2 #123
Implement Widget Settings with descriptions...
@kcharwood mentioned you: Got this working in SwiftUI @rjonesy, but having some problems with iPhone frame overlay...

[brianlovin]

Chatting with the team about this, and one thing that's going to be important as we support more push notification types in the future is to not bury the reason too deep. How about:

Title: {Reason}
Subtitle: {owner/repo} {issue/PR title} {number}
Body: {snippet}

So:

@kcharwood mentioned you
weather-line/weather-line-2:  Implement Widget Settings with descriptions #123
Got this working in SwiftUI @rjonesy, but having some problems with iPhone frame overlay...

In this world, the subtitle is very likely to truncate, which would cut off the number, which probably isn't very useful the push context anyways.

[rjonesy]

I figured future expansion was why. Makes sense.

If you're telling me {owner/repo}are more important then I don't see a better solution either. I like what you got! I don't belong to enough repos or get enough variety of notifications to know if the issue title provides sufficient context to come before owner/repo.

👍

[brianlovin]

If you're telling me {owner/repo}are more important

This is usually the "root context" - what state of mind I need to be in when evaluating what this might be about, what the codebase looks like, my relationship to the code, etc. But for people who primarily contribute to one repo I can see how this might feel a bit redundant, good point!