Allow re-requesting the same icon

[moertel]

Currently, if an icon is requested, it shows an Already requested tag and cannot be requested again.

Because I offer both free and premium requests, I've had a few users reach out and ask whether they could "swap" their free request for a paid one to speed it up. I'm currently directing those users to use the Clear Icon Request Data option in the Settings but I was wondering if it would be better to just display a warning dialog to those wo want to re-request?

The proposed flow:

• User taps the [_] checkbox on an icon
• If the icon was not yet requested, the checkbox is now [x] enabled
• If the icon was requested previously, a dialog comes up

  • You already requested this icon. Are you sure you want to request it again?
    Add request Cancel

  • Add request will [x] enable the checkbox
  • Cancel will do nothing and leave it [_] unchecked

I wouldn't want to mess with the existing implementation and hide this new behaviour behind a feature flag such as allow_duplicate_icon_requests (or a similar name).

Any objections to this approach?

[sarsamurmu]

Nope, no objection from me

[moertel]

Alright, then here's the PR: #160

Contrary to what I said above I now did change the default behaviour slightly because I believe it makes no sense to let users select requested icons only to present them with an error once they tap "Send". Instead they'll now see a dialog immediately when they tap the (disabled) checkbox.

[walrus543]

Perfect like that.
Select all shouldn't select the already requested icons.
Great new feature. Thanks.

Actually it would be great to also let users send a request for an already supported icon.
Basic use case: the app has a new original icon so the custom one should be updated too.

[moertel]

Thanks a lot! Yeah, I can see how it would be useful to have already supported icons be hidden behind a "Show all" button and then allow to re-request them. I have a few concerns, though:

1. How do I prevent a situation where a user is just unhappy with my icon drawing and re-requests it? (Worse still, if they request it with a Premium request... 🙃) I'm mentioning this because out of all the "wrong icon" feedback I received, it was 25% legitimate change requests and 75% just not getting my sense of humour.
2. I feel like legit icon changes (such as for X/Twitter and Kontist) should be prioritised higher than regular requests, since they directly affect the quality of the icon pack. But how to signify that? An entirely new queue?

I'm leaning towards offering a generic "icon feedback" process and making it different from regular requests. I could imagine a button "Report wrong icon" that loads all installed apps with already themed icons in a dialog and does not count as a request.

@justinkruit as you're the maintainer of an icon request manager, curious to hear your take on this.

[justinkruit]

@moertel heyy!

With a quick overview what is being suggested, it would require to store this "feedback" in some different way and add a good way to visualize it. For now I don't really see much added benefit for this functionality. It's the same as Pacific doesn't (officially) support premium requests, so then that would already have priority over this feedback system.

Could be I'm just missing the importance of it, haven't developed for a while on Pacific.

[moertel]

Thanks, @justinkruit! Well, it could be a third queue in Pacific then, I guess. (Zero-effort workaround)

@walrus543 Do you receive your requests via email or via a tool? Where would you want to receive them?

Overall, I really wish there was a sort of two-way feedback system where users could request icons, designers could acknowledge the request (lock it in) but until then users would be able to change their requests. Designers could also decline requests for whichever reason (Lcky Ptcher comes to mind) and this would display to users...

Wishful thinking :) But happy to make the re-request possible.

[walrus543]

@moertel Sorry for my late reply... I only accept requests by email. I have custom rules and auto-extraction with Thunderbird.