Microsoft has started redirecting users from IE to Edge automatically when those users visit a site that doesn't support IE, and site owners can volunteer to have their sites added to a list for that redirect to occur.
It may be a a good idea for WMF to let MS know to add WMF wikis to that list.
I don’t think users should be forced to use Edge. Wikimedia sites do, and expected for a long time to continue to do, work in Internet Explorer. The popup stating This website doesn’t work with Internet Explorer
wouldn’t be true—it works, just with a somewhat degraded performance. Maybe we can add a custom advice about switching when the user tries to access particular features that don’t work in IE. For example, if VisualEditor stops working in IE, we can show a popup when the user clicks the edit tab—and not earlier—asking them whether they want to use the wikitext editor or switch to Edge. If Microsoft offers a feature to redirect the user to Edge (including moving all the data) upon user interaction, we can use that, but the unconditional redirection is too aggressive considering the level of IE support we have; it will be appropriate only once IE falls out of Grade C support, which is quite far away.
Where was the discussion that lead to this new treatment of IE11? This direction isn't so much as mentioned at the only relevant Phab task I know of, which is phab:T178356.
Hello Izno, thank you for asking. I'm working on getting answers to your questions (and I'll document/link to the answers provided).
Hi @Izno. I can offer some clarity, I think. This decision arose from a project that used a relatively new technical decision making process called the Technical Decision Making Process. One outcome of this process was a recommendation to limit support in the ways mentioned on this page. Given the engineering recommendation, it was decided that this was a "product decision" due to the impact it would have on users.
I then led a cohort of engineers, a designer and product manager representing our performance team, our emerging markets product team, our accessibility initiatives, and three product development teams through some information gathering and discussion to unanimously confirm the recommendation. Let me know if you have any follow up questions or concerns. Thanks!
That does not answer my question. I am not looking to know who was involved internal to WMF. I am looking to know where the discussion was. There are multiple points on that (new) process page that indicate Phabricator should have known that this was a decision being discussed. Where was that discussion?
Hi @Izno, I answered with the internal decision making process, because I am unaware of an external component to this particular decision. As is the case from time to time, this product decision was made without community involvement and the focus is now on making sure we communicate it out.
As for the lack of public documentation for the broader Technical Decision Making Process (TDMP) that led to this recommendation, an abbreviated process was run because the lack of decision (not this decision) was holding up a high-priority project, specifically our Desktop Improvements project, specifically this. The team responsible is working on getting documentation, post-hoc out (as with this part of it) and I am told something should be on wiki about it within the month.
Okay, so this "decision" is more or less an outcome of the earlier, RFCd, Vue.js decision. That would be good to include on the main page probably.
One would have thought one would have seen an RFC for that. (No, only a half joke.)
In terms of relevant Phabricator tickets, in addition to the main ticket about IE11 support, this ticket discussed the changes in ResourceLoader which will allow specific modules to start declaring themselves as ES6-only.
On a practical level, that is the feature development teams will begin using on a case-by-case basis to drop IE11 JS support where it is deemed appropriate (starting with brand-new features). Major existing UI components like Visual Editor will probably not go down this path for quite some time.
Additionally, not shipping the JS version of a new feature to IE11 users may not always equate with not shipping a feature to those users at all – in many cases it will likely make sense to provide a no-JS fallback that would support users of IE11 (as well as users with JS disabled for whatever reason). The ability to designate certain RL modules as ES6-only is well suited to this kind of progressive-enhancement approach.
I think it’s a pretty important user-facing change, so I went ahead and added to next week’s Tech News: m:Tech/News/2021/10.