Disable clicking anywhere on the page while content loads from the WhoColor API

Is this required? The content sometimes takes quite a while to load.

@Prtksxna - Great question. I'll ask the team if there's a technical reason for this. If there's no technical reason, I'll remove it.

Update: We'll remove the "Disable clicking anywhere on the page while content loads from the WhoColor API" requirement.

Based on T229714: Spike: Investigate Possible Errors for WWT [4 hours]:

For the rest of the errors we can show a generic Something went wrong message. As mentioned in T229714 we can give a way to Contact us. I am wondering what the right avenue for that would be—a talk page or a phab task or something? It would be awesome if the link would take them to a place where some stuff (like the page that caused the error) would be pre-filled.

As mentioned in T229714 we can give a way to Contact us. I am wondering what the right avenue for that would be—a talk page or a phab task or something? It would be awesome if the link would take them to a place where some stuff (like the page that caused the error) would be pre-filled.

I would suggest https://meta.wikimedia.org/wiki/Talk:Community_Tech/Who_Wrote_That_tool as a feedback forum, since many don't use Phabricator. We could use preload parameters to automatically include the relevant page.

I'm also wondering what's the best avenue for "Contact Us."

My concern with using the Talk page is that we may be flooded with messages (if there's an influx of API errors at some point, for example). This may make the Talk page unwieldy and difficult to parse through in the future, especially if there are repetitive messages related to the same problem.

For this reason, I believe that a Phabricator task associated with errors would be easier to manage. While not all users engage with Phabricator, perhaps enough do that they can report common errors, and/or WWT users (who are more likely to be power users) may be more likely to have Phabricator accounts? I'm overall open to suggestions, so I'm curious to hear your thoughts, @MusikAnimal & @Prtksxna.

@MusikAnimal, I didn't know about preload parameters, yeah that is exactly the kind of thing I was hoping for.

@ifried, I see your concern and I think its valid. Since the posting wont be automatic and the person will still have to fill out some text and sign, I don't think we'll get flooded as often, but yeah, it might happen. If we do do it on a talk page I propose it be a subpage on Talk:Community_Tech/Who_Wrote_That_tool instead of the main talk page. The phab idea is good too, and that is where we point people to from other tools too, but since this is so on-wiki I worry if people will be very turned off with a link they aren't used to.

You can definitely expect more, sometimes redundant feedback with an on-wiki venue. The other advantage to using Phabricator is those who do file a bug probably know how to and will include other relevant information (such as their browser). The downside is of course that if they don't use Phabricator, they might not ever report the issue and we won't find out about it. Maybe the "Contact us" message could offer both venues? XTools has two links; "Feedback" (on-wiki forums) and "Report an issue" (Phabricator), and that seems to have worked well. Pageviews Analysis meanwhile has a "Report an issue" link that goes to the on-wiki forum, and I do get a lot of repeat questions, but it's been manageable.

I've discussed the "Contact Us" question with @Prtksxna. We talked about the fact that: a) bug reports & issue outreach on the general Talk page aren't ideal (because they may clog the page with redundant content), and b) bug reports on Phabricator aren't ideal (since not everyone has Phabricator accounts, which may discourage users from reporting issues). As a middle-ground solution, we've talked about perhaps redirecting users to discussion on-wiki, but in a distinct section/heading that doesn't muddle the general Talk page content.

Also, @MusikAnimal brought up an interesting point about allowing both options (since Phabricator tasks, if people do write them, tend to be more descriptive and helpful overall). We can discuss this in the Estimation meeting later today.

What colour should the 'contact us' link be? It's blue at the moment:

In T226760#5426900, @Samwilson wrote:

What colour should the 'contact us' link be? It's blue at the moment…

Can we keep it the same color as the text—#fff—and add an underline?

Thanks; done:

PR for this is https://github.com/wikimedia/WhoWroteThat/pull/34

Ready for review.

• The text (in white) should read (as default) "API Error: Please refresh the page or try again later."
• For 200 OK, the text should read: "API Error: Please try again later."

I am a bit confused as to which of these errors it should be. At the moment, the error is: "API Error: Please refresh the page or try again later." which seems reasonable.

I have seen this happen when the WhoColor API returns with "Requested data is not currently available in WikiWho database. It will be available soon."

• For 429 Too Many Requests, the text should read: "API Error: Please try again later."
• For 400 Bad Request, the text should read: "API Error: Please contact us about this issue."
• For 503 Service Unavailable, the text should read: "API Error: Please contact us about this issue."

I setup an intercepting proxy and changed the responses from the API in-flight.

Above error messages confirmed.

Also, for any other random API response (e.g. "301 Moved Permanently", "502 Bad Gateway", "418 I'm a teapot") error message is: "API Error: Please contact us about this issue."

• For issues when the server is unreachable, the text should read: "API Error: Please contact us about this issue."

Simulated this by throwing away the response from the API.

• The "contact us" text can be linked to a sub-heading of the Who Wrote That talk page. [active discussion about exact placement is in comments below]

Links to https://meta.wikimedia.org/wiki/Talk:Community_Tech/Who_Wrote_That_tool.

• The error text should be implemented in a way that takes into account that we may have more targeted messaging based on specific errors in the future.

I don't know how to test this.