Provide entry point, step-based guide and better UX for end users about dont-kill-my-app

[yccheok]

Agree. This site might be the key, to raise end users awareness. Nothing will change, if only developers aware on this issue.

AlarmManager will continue broken.

However, if end users aware of this, that can pressure Google to do something about it. At least enforce a unify battery optimization policy, or at least make AlarmManager not impacted by battery optimization policy.

This site is already published in hackernews. But that is not enough as hackernews doesn't target ordinary end users.

What if, this site is published in Forbe, Time, ...?

[Artaud]

Many thanks for the great points. I agree with most of them.

I'll tie points 1,2,3,8 to the app URL parameter.

Not sure about point 4. With most of vendors, we currently don't have specific steps for specific devices, so maybe we might think about this later when the pages are more cluttered?

5. I believe this is not an issue as the main navigation lists device names?

6. We renamed the Stock Android to Google (Pixel, Nexus) - what do you think about that?

7. Agree completely. The only issue is getting the screenshots. This is something we'd need from the developer community as we don't have access to most of the phones to generate the screenshots.

8. No clue how to do that. Technically, this is easy, but keeping it up to date sounds like an impossible thing, and frankly, in the age of Google Translate, as imperfect as it may be, I think we're still never going to beat that...

Let me know your further thoughts....

[Artaud]

@yccheok

However, if end users aware of this, that can pressure Google to do something about it. At least enforce a unify battery optimization policy, or at least make AlarmManager not impacted by battery optimization policy.

This is a great point and ideally the ultimate goal of this site. If Google would be able to keep the battery optimization under control, the battle is won.

[ocram]

Thanks for your feedback!

I'll tie points 1,2,3,8 to the app URL parameter.

Yes, that would be perfect.

Not sure about point 4. With most of vendors, we currently don't have specific steps for specific devices, so maybe we might think about this later when the pages are more cluttered?

Of course, you don’t have specific steps for every device. But the problem is that if you name it just “Samsung”, users with an older S6 will visit the page and try the steps that may actually be for the latest S9. So there has to be some differentiation. Perhaps just “Android version” as a next step. But with another step in the navigation, the Android version would still work better than listing all the different Android versions below each other in a long wall of text (and some screenshots).

I believe this is not an issue as the main navigation lists device names?

Sure, where device names are available, that’s always better than using an Android version name in communication towards end users. Sometimes, we may have to distinguish between “S6 (Android 5)” and “S6 (Android 7.1)” though where Android updates have been introduced with major changes.

We renamed the Stock Android to Google (Pixel, Nexus) - what do you think about that?

Yes, that’s great. Although where Motorola or other vendors with near-stock Android have the same issues, we may have to use an “alias” that has the same content as the Google category.

Agree completely. The only issue is getting the screenshots. This is something we'd need from the developer community as we don't have access to most of the phones to generate the screenshots.

Absolutely. As I said, I would be willing to contribute, and others will surely be, too.

No clue how to do that. Technically, this is easy, but keeping it up to date sounds like an impossible thing, and frankly, in the age of Google Translate, as imperfect as it may be, I think we're still never going to beat that...

Well, as I said, translation is definitely nice to have, but certainly not as critical a factor as the other issues. We should definitely postpone this, at least.

[Artaud]

I've pushed the ?app URL parameter in a1d6499

You can now use params like https://dontkillmyapp.com/nokia?3&app=JStock and all occurences of "your app" will be replaced by JStock, and only the relevant information for end users will be shown.

[ocram]

Thanks a lot!

This is awesome, and solves most of what this issue is about. The addition of screenshots (or at least some infrastructure for that, e.g. guidance on where to add them) would be something that’s left.

What makeSiteUserFacing does is fine, though it’s not really sufficient to apply the text replacement to p only. It should probably be #user-solution-section instead, as the text “your app” does also occur in ul, etc.

Moreover, in #user-solution-title, you could probably replace Solution for users with just Solution as it’s the only thing left if it’s a user-facing page.

[Artaud]

yep I've noticed, I'll push a fix in a few moments

[Artaud]

fixed with 0ebb6aa

[ocram]

Thank you!

The last thing I noticed is that you cannot open /?3&app=JStock to have this set on the overview page. At least, the query string doesn’t get appended to the individual vendor links, which works on the vendor page, though.

Finally, I guess, we’d just need a single short paragraph of documentation somewhere to tell developers that this is possible and that they can refer their users to the pages with a custom link.

[Artaud]

fixed with 6004924

docs are coming tmrw :)

[Artaud]

Docs have arrived in the API section, including also a Java example on using the JSON API in a webview in an app for quick usage

[matejdro]

Maybe adb-based solutions should be grouped up under Advanced title or maybe even hidden by default? Most users do not know how to do these and it might overwhelm them or turn them away from even doing basic solution above.

[ocram]

@Artaud Thanks a lot for addressing many of the points outlined in the original post!

Still, I would say your current website (dontkillmyapp.com) is good for developers, perfect for drawing attention to this problem and building public awareness, underlining the need for change, but it’s hardly perfect for end users.

Now maybe that is what you want. Attracting attention from the press or even vendors is great. We definitely need that for this problem.

But supporting users with these problems, and thus improving user satisfaction, is important as well. Throughout the last month, we have been making public the solution that we have been using as well. Our solutions seem to serve different purposes, but in any case, they are complementary.

I’m sure multiple solutions can benefit from each other and from an exchange of ideas. Or perhaps you’re even willing to further improve this project for end users, which would be great.