https://bugzilla.wikimedia.org/show_bug.cgi?id=46306
--- Comment #77 from Kunal Mehta (Legoktm) <legoktm.wikipe...@gmail.com> --- (In reply to comment #75) > There are several separate issues here: > > 1) Does ULS have an unacceptable performance impact on some users which needs > to be mitigated; Yes. > > 2) Does ULS include functionality that is simply irrelevant for some users > while cluttering UI; Irrelevant for some users, yes. I don't personally think it is cluttering the UI. > > 3) Is there a specific "third party" vs. "WMF" issue here. > > I think the third point is a red herring. If we agree that there are real > issues to be solved, then we should solve them for everyone, not just > hypothetical third party ULS users who have a hypothetical interest in > offering > users ULS while also offering them the option to disable it on a per-user > basis. Okay. > > The first point, performance, has been an ongoing issue with ULS. The initial > release of ULS caused insane amount of font-loading to occur on pageviews > with > language links. That issue was unfortunately unresolved far too late, which > probably caused a lot of users to identify ULS with negative performance > impact. Loading of fonts for sidebar links has been disabled since late > September, and the new autonym font should offer a solution for this issue > once > and for all: > https://blog.wikimedia.org/2013/10/28/the-autonym-font-for-language-names/ > > This is by far the biggest performance issue with ULS -- we're talking about > megabytes of payload on some pages. I suspect, though, that even with the > autonym font, we need to continue to improve font-loading behavior. It's > possible to force use of system fonts; however, I don't see an option to > disable font-loading altogether. Having that be an option within ULS itself > may > be useful for users of slow connections. Has that been discussed? I don't think so. While webfonts are pretty large, ULS itself is also large. > > The JS/CSS payload is less of an issue, and the team has already made some > optimizations, though there's probably still room to do more lazy-loading so > that ULS truly only adds payload to page requests when actually used. I've > CC'd > Ori on this bug from his perspective as Performance Engineer, though there > are > probably other relevant bugs where this discussion is occurring/should occur. I disagree that JS/CSS payload is less of an issue. On the latest master of ULS + MediaWiki master, the top 4 entries in mw.loader.inspect() are from ULS: 'jquery.uls', 'jquery.uls.data', 'ext.uls.init', and 'ext.uls.webfonts.repository' (118.67KB total). The next extension on the list that I have installed is Echo, which has a total of 14.79KB (not including common dependencies like mediawiki.jQueryMsg). On enwiki's main page the results are similar, except for jquery.ui being loaded from somewhere, but I understand that's already on its way out (bug 47145). > > Regarding the question if ULS should be "disable-able" for some users > altogether, the reason I'd argue against it is that ULS is basically a core > site feature: changing the UI language and language settings. It's like > hiding > a part of the preferences section. It's where ULS has impact that goes > _beyond_ > what you'd expect from a preferences/selection feature that preferences or > changes to the default behavior are more appropriate. I disagree. You can go to Special:Preferences and change your language settings there. ULS even conveniently adds a link in that section to open the ULS language selection pane. For people who don't change their language settings every few minutes or ever, that feature isn't needed. > > In addition to the font issue, the only other aspect of ULS where that's true > is arguably the input method selection. This is really the only part of ULS > that adds true clutter to the page, because it pops up in every edit field, > taunting you with a feature that may be completely irrelevant to you. It > _can_ > be disabled and hidden with a single click from the menu. I know the UX folks > have thought about a way to make the selection control itself less annoying, > e.g. embedding it into form fields rather than having it come up on focus > below > the field. IMO we should be focusing on improvements like this. I like that option because there's a way to turn it off. For people who find it useful, they can keep it enabled, but for people who don't, they can turn it off. The rest of ULS needs an option like this too, simply because not everyone needs/uses/wants it. Right now wikis are resorting to ugly hacks like https://en.wiktionary.org/w/index.php?title=MediaWiki:Common.js&oldid=23352360 to disable ULS. Providing a sane off switch is an improvement. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
