Page MenuHomePhabricator

All skins should use WikimediaUI OOUI theme
Open, LowestPublic

Description

Today I’ve submitted my WikimediaUI-inspired main page of Russian Wikipedia for community discussion.

One of the feedback points I’ve got is that the page uses, as an editor called it, ‘mobile blue buttons that are foreign to desktop interface’. This editor uses Monobook skin, and he probably never seen WikimediaUI outside of mobile version exactly because of this. Right now, for some reason, Monobook uses non-standard Apex theme. This, I think, causes confusion for Monobook users when they see the interface that is pretty standard-looking for default Vector skin in their own one.

I suggest that Apex theme should not be used in any Wikimedia skins, so the users of any non-standard ones will be accustomed to a familiar interface no matter which skin they are on. It would benefit both the users and the developers to have the same standardised interface across all the skins in Wikimedia projects.

Event Timeline

stjn created this task.Apr 19 2018, 6:06 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 19 2018, 6:06 PM

stijn, thanks for your open words!
As much as we've been focussing and improving our WikimediaUI interfaces (Vector, MobileFrontend with MinervaNeue skin) on a variety of levels (consistency, usability or accessibility) we're also aware of being careful about change in order not to disrupt long-term users, especially editors, workflow.
Enforcing a change on them is not the way we're choosing, but being careful of remaining in a maintable and product-feature rich environment, there are compromises that they have to be willing to make.
I don't think proceeding here, gains us a lot. We rather long for explaining the advantages of switching over to a modern interface.

Volker_E triaged this task as Lowest priority.Apr 20 2018, 12:53 AM
stjn added a comment.Apr 20 2018, 12:59 AM

Enforcing a change on them is not the way we're choosing, but being careful of remaining in a maintable and product-feature rich environment, there are compromises that they have to be willing to make.
I don't think proceeding here, gains us a lot. We rather long for explaining the advantages of switching over to a modern interface.

I wasn’t exactly talking about ‘enforcing a change’, especially since I don’t think they (meaning those editors) chose using Apex theme instead of WikimediaUI. That was maybe a choice of convenience in the era when jQuery UI was used a lot more in Wikimedia projects than OOUI, but now it seems like a product of its time.

It should be, of course, communicated to users that their buttons and forms will be looking differently but ultimately there is no benefit in having this theme difference across the existing skins, in my opinion. I am, of course, not talking about a total revamp of skin styling to match WikimediaUI, but about deprecating Apex theme styling from the interface elements that are common across multiple skins.

stjn added a comment.Apr 20 2018, 1:12 AM

How this differs from T122014?

That task is about using OOUI in backend of different extensions (not theme-specific), this task about using a common OOUI theme in frontend (at least on Wikimedia sites). They are somewhat related though, I would guess.

Volker_E edited projects, added Design; removed Design-Research.May 28 2018, 8:56 PM
Isarra added a subscriber: Isarra.May 29 2018, 12:00 PM

I'd maybe recommend against this. While most wikimedia-deployed skins currently have at least mostly similar visuals, this is not necessarily going to remain the case going forward, and we do need to continue to effectively support different themes so that we retain the flexibility to make new ones when the need does arise later on, as well as for third-party support, as they will likely just want totally different ones anyway from the start. Otherwise, consolidating entirely, we lose the bug-testing that MonoBook's use of Apex currently gives us, and this could make it very easy to make breaking changes without even realising it until much, much later when it's too late to really do anything about it.

I do agree that MonoBook's use of Apex is strange, since if anything I'd say WikimediaUI matches MonoBook's visual styles better than Vector's, and Apex matches Vector's better than MonoBook, but... from a technical standpoint? I think having this really is quite valuable for now.

stjn added a comment.May 29 2018, 12:02 PM

If we have this difference just for the purpose on testing, then it’s even less valuable. I mean, we have Pig Latin English somewhere in the code for testing language variants, doesn’t mean that English Wikipedia should have Pig Latin English as a default variant available in the project. Production should not be used for the purpose of bug-testing.

Well, ideally most skins should have their own, anyway. They're different layouts, different visuals, different expectations, and anything that doesn't match that (the forms) is going to jar regardless of if it's consistent across different skins, because it's still not going to be consistent with the current one. It's just that nobody's implemented them yet. But on the other hand, if we really don't have any other themes anywhere, then that's not exactly a reason to keep multiple now, as you say. That'll likely just make it more difficult to make changes to the base thing in the meantime before we do diversify.

I do completely disagree with 'Production should not be used for the purpose of bug-testing.' This is a UI thing - we can't always catch the problems without actual users testing it in practice, by using it in practice. We need that. Yes, we should be catching most of it before it goes to production, but we will never catch all of it no matter how much information and foresight we have.

Filed T216703 about MonoBook specifically.