* customers might have complained that the site didn't work on mobile when the desktop site was requested; this may have led to a burden on their support team, and a manager might have decided to block usage instead of fielding support requests
* a team internally might have been spending a lot of time chasing down bugs for desktop on mobile, and a manager decided to officially not support desktop on mobile; instead of just stopping support or carefully triaging tickets (e.g. distinguishing desktop on mobile from desktop), they just decided to block desktop on mobile access
* a team might have been burdened by being required to fix all bugs that came in; instead of dealing with the problem properly (e.g. continuing to allow desktop on mobile but not officially supporting it), they officially killed support to avoid having to work on it
* there could be some KPM to reduce bug reports over some period of time; they killed access to the non-supported use-case of desktop on mobile to make numbers look better
Not really a smart decision in any of these cases, kind of stupid, honestly; but not really nefarious either and the kind of decision that can be made sometimes at a larger place with politics.
I actually think all these problems could actually be fixed more easily but just showing a "we really think you should download our app" banner in this case. Let the user know they're going off the reservation but don't explicitly block them.
As someone who once used Slack's website on mobile, I can assure you they didn't have a team spending a lot of time chasing down bugs with that configuration.
As mentioned above, this has to be a very small number of users who are sophisticated enough to bother instructing chrome to request the desktop site. So the bug burden would be small on an absolute scale, and could be ignored entirely by simply telling these advanced users the desktop-on-mobile was "as is" and not supported.
The site I work on has hundreds of millions of visitors a month. A double digit percentage of our overall traffic uses our desktop site on mobile. It’s not the same use case as Slack but I’d bet it’s bigger than you think.
Also, bug burden shouldn’t be an excuse if your market cap exceeds $10bn.
Aren't you agreeing with me? The important thing is that, as a fraction of users, the number of people asking for this is small. Therefore, given the size of the company, the resources devoted to it are relatively small.
No. I think when you are big enough, a feature with even 1% usage is big enough to dedicate resources to. Slack made $168M last quarter. 1% of that deserves at least 1 eng and 1 QA full time.
Where do you think we disagree? I am arguing that bug-fixing costs are not a good justification for Slack to ignore requests for the desktop website from mobile devices.
* customers might have complained that the site didn't work on mobile when the desktop site was requested; this may have led to a burden on their support team, and a manager might have decided to block usage instead of fielding support requests
* a team internally might have been spending a lot of time chasing down bugs for desktop on mobile, and a manager decided to officially not support desktop on mobile; instead of just stopping support or carefully triaging tickets (e.g. distinguishing desktop on mobile from desktop), they just decided to block desktop on mobile access
* a team might have been burdened by being required to fix all bugs that came in; instead of dealing with the problem properly (e.g. continuing to allow desktop on mobile but not officially supporting it), they officially killed support to avoid having to work on it
* there could be some KPM to reduce bug reports over some period of time; they killed access to the non-supported use-case of desktop on mobile to make numbers look better
Not really a smart decision in any of these cases, kind of stupid, honestly; but not really nefarious either and the kind of decision that can be made sometimes at a larger place with politics.