https://bugzilla.wikimedia.org/show_bug.cgi?id=46306
Erik Moeller <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #75 from Erik Moeller <[email protected]> --- There are several separate issues here: 1) Does ULS have an unacceptable performance impact on some users which needs to be mitigated; 2) Does ULS include functionality that is simply irrelevant for some users while cluttering 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. 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? 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. 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. 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. Improving the user experience in this fashion also makes sure we reach all users, and not just the small percentage who are annoyed enough to change a preference. Preferences are a form of clutter, too, and we should be very thoughtful and intentional when we add them. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
