search

zixpo / candybar

Dashboard for Android Icon Packs. Supported by the community.
Apache License 2.0
285 stars 53 forks source link

[FR] Different kind of request for re-requesting already supported icons #166

Open walrus543 opened 7 months ago

walrus543 commented 7 months ago

Hi, Sometimes original icons change and the already supported/custom icons are no longer relevant. It would be great to allow users to send a request for supported icons.

mhmatthewhugley commented 6 months ago

Hi, Sometimes original icons change and the already supported/custom icons are no longer relevant. It would be great to allow users to send a request for supported icons.

  • The request limit has to be respected.
  • A comment to give a reason why the user requests it again should be mandatory. Short text as we do for the bug report.
  • Dedicated string in the dashboard_configurations.xml :
    <string name="regular_re_request_email_subject">Your text</string>
    <string name="premium_re_request_email_subject">Your text</string>

Thank you.

I agree this would be a very useful enhancement.

Donnnno commented 6 months ago

I think it's already in Candybar with the latest release:

https://github.com/zixpo/candybar/pull/160

@moertel can you confirm it?

walrus543 commented 6 months ago

@Donnnno No we can only send a new request for unsupported apps.

CDOCesar commented 6 months ago

It would be great to revamp already existing icons that changed their image

moertel commented 6 months ago

@Donnnno, adding to what @walrus543 said: The functionality implemented with #160 is that a previously sent free request can be "upgraded" to a premium request as long as the icon is still unthemed. I named the title a bit poorly, so that's where the confusion comes from.

Speaking to the feature of re-requesting already mapped icons, I probably won't implement nor use it (but Sarsa might). In the few cases where an icon changed and the activity name did not (super rare! maybe 3 times), I always had someone email me about it.

  1. There is no use in receiving the activity name via the app because it stays constant
  2. There is typically no use for a voting system because it should be considered a bug (i.e. highest prio)
  3. The majority of requests of this type is from people simply disliking the current mapping (e.g. a lightbulb for a home lighting system instead of the company logo), wasting my time if this was a legitimate queue

Number 3. might be highly personal/specific to my app but I wanted to bring it up here because it's a major issue for me.

How would you all think about a "Report a problem" button at the bottom that would open an email dialog?

walrus543 commented 6 months ago

If a user doesn't like the custom icon then he shouldn't be able to send a request, that's right. However I'd like to allow my users to send an email about custom icons that are outdated (because the original has changed) or because there's a bug with the existing custom icon.

"Report a problem" can be a good choice and explicit enough. He could select the icons to report. We can't base a report only on the manual description provided by the user. We need technical information such as the package name so they should be added to the body of the email.

My automation tool merges the request if a new activity is detected. The package name is the same so I don't have to work on the icon. However I have no solution to detect if the original icon has changed so I don't plan to check them manually :-)

Thank you for your interest!

moertel commented 6 months ago

Sorry if I get hung up on that so eagerly:

We can't base a report only on the manual description provided by the user.

Why not? In all the cases where someone emailed me, I could quickly locate the app name in one of my XMLs, then open the app listing with the package name I already have. It's not streamlined nor convenient - granted! But it happens to me so so so rarely that I've never felt the need to build a workflow around it.

How often does this happen for you, if you don't mind me asking?

And sorry if it came across that way but I'm in no way opposed to someone building this functionality. I just wanted to give my 2 cents why I think it's not a good investment of my own time and that there's a real risk of abuse. :)

kshitijdeota commented 6 months ago

I rarely do receive a redesign request or a request to update the changed package name for existing icons. (like 'twitter' -> 'X', new google app icons) In such cases I ask the user to submit a bug report along with the list of apps they want fixed. List has never exceeded 3-5 icons, in my case all the users have been very supportive of the process so far.

If any of the icons from the above list do not pre-exist in the pack, I ignore the request or ask the user to use the conventional "icon request" method.

walrus543 commented 6 months ago

The idea is also to improve the user experience. Having to use a bug report isn't convenient and it's definitely not a bug when the original icon has been updated. I can't say that I often receive such requests but it's clear that several custom icons are outdated in my icon packs and we would receive more requests if this feature were available. We have users here who can confirm I guess.

No problem @moertel this feature request wasn't especially directed to you 😉

kshitijdeota commented 6 months ago

I would second that with @walrus543 about the bug report user experience. Often I do need to explain how and why a "bug report" is needed to send over a list of outdated icons. 😄 Maybe an "icon update request [free/premium]" with side-notes feature could be introduced. Not my place to comment on ease of integration of such a feature without over complicating things, let the experts speak. 🙂