No, I agree that they should improve the handling of error conditions. A good UI should never throw errors at a user unless it is absolutely necessary, and if it does then generally speaking it should hide technical details and give a user friendly response. So for example right now _everyone_ should probably see simply a positive centric message like "We will be making new games available in the future subject to availability from our partnering game publishers. Currently there are no games available through this special offer however we will make announcements when new games become available." or words to that effect. The back end should be disconnected from Steam, and nobody should get any errors or even know what is happening in the background or if it is even trying to connect since there is no real reason for it to connect unless there are actually game offers on display (IMHO).

This solves problem 1 of not knowing about why it doesn't connect, because the only reason someone doesn't know why it has trouble connecting is that it's trying to do something and it's telling them - both technical details nobody needs to even know. If there is actually connections to anything going on in the background and errors occuring, that's something to spit into a log file and email an admin to look into and not display errors to a user that then wants to know WTF is happening.

When the service is actually active and has games available, they should optimize the service to reduce the number of connections as much as possible due to the Steam API's limitations. No user should be able to reload the page 100 times to get through and burn through that many Steam API requests. They should queue user interest and if a user reloads or repeats the request on the same account from any computer or browser while one is in the queue, it should ignore multiple requests either entirely, or calculate from the current request rate a projected request rate for the day to calculate whether there might be spare unused requests at the end of the day, and in tight loads refuse more than one attempt per day (or longer) from one user, while if the queue and prediction is small - to perhaps allow more than one request from a user in a day in case they've added a game to their Steam account since the last poll. However, they should also cache results from previous queries to Steam for that user and reuse that data for some time rather than re-polling Steam. There are many other optimizations that could be done, and they may actually be doing some or all of this already for all I know.

I look at this from an engineering perspective. The problem isn't that users can't connect, it is that the underlying back end should be doing things in as optimal a manner as possible to minimize problems, reduce connections and traffic to Steam, reduce/eliminate user initiated abuse such as pounding on reload or using bots to hammer GOG's connect web page, etc. and they should minimize any error messages or other negative anger-inducing screens shown to users. Users only need to see whether the service has games to offer at the moment or not, and if not, do nothing and show a friendly message of what might come in the future. If there is something there now, then allow them to link their account to Steam if it isn't already and make sure they know that due to technical requirements of the Steam API they must make their Steam profile public in order for the service to work. If the system is not under load, process it in real-time and inform the user when the information is available about what games they have and whether they are elligible - there should be a time limit on that of maybe 30-60 seconds or so, and if that can't be met either due to GOG server load, Steam server load or API throttling, or some other errors, it should display a message like "Thank you for using GOG Connect, we will send you a message when your results are processed. Would you prefer to be sent a private message on GOG chat, or a private email message [enter details below]?"

They may need to massage the message etc. to the technical details of the situation, may have to include "Your request may take n hours/days for processing", and/or other special handling with the goal being to maximize the end user experience as much as is technically possible while reducing bad experience, user seen error messages etc.

Users do not like errors, users do not like being told "no" or seeing a GOG bear etc. That should all be avoided as much as possible. If all of what I say can be and is done, then all the debates above more or less become a moot point.


Question: How many engineers does it take to change a light bulb?
Answer: Does it have to be a light bulb?