Page MenuHomePhabricator

RFC: Where to implement Desktop Improvements project
Open, NormalPublic

Description

Background

As part of the Wikimedia Foundation’s Medium term plan, the Readers Web team will be making significant improvements to the desktop experience of Wikimedia projects.

Although Wikimedia desktop sites have evolved over time, their visual appearance has not changed significantly since the Vector skin was introduced almost a decade ago. There have been many efforts to improve the desktop interface through extensions, gadgets and templates, but the now antiquated appearance of the Vector skin has always stood in sharp contrast to these modernization efforts.

This is why we feel that in order to provide a consistent and unified experience on desktop, we have to improve the underlying appearance of the skin itself.

Project Goals

The goal of the Desktop Improvements project is to make Wikimedia wikis more welcoming to new readers and new editors while not disrupting the workflows of our most engaged community members. By overhauling the visual appearance of Wikimedia projects, we hope to strengthen the identity of the Wikimedia movement as a whole for current and future generations of Wikimedians.

Decision Deadline

We want to have a decision by October 31st, 2019.

Project Scope

Although ongoing research, design and community consultations will ultimately determine the final shape of the Desktop Improvements project, we expect to make significant changes to the visual appearance the desktop UI (preliminary designs were shared at Wikimania and are publically available). We will not be modifying content in any way. Also, we will be ensuring that customization features such as system messages, gadgets, user scripts/styles all continue to function.


Problem statement

Project Requirements

The Desktop Improvements project by nature affects everyone who interacts with Wikimedia projects so we must account for a multitude of stakeholders with a range of requirements.

The current list of requirements is as follows:

  • The ability to make incremental change. Users shouldn’t experience an abrupt change to their workflows.
  • The ability for users to opt out of the new experience.
  • The ability to differentiate a Wikimedia site (e.g. Wikipedia) from a third-party site running MediaWiki.
  • The ability to run multivariate tests on the UI changes.
  • UI customizations are not restricted. This includes users styles/script and per-wiki customization of menus and other UI elements via system messages.
  • Templates continue to function as they currently do.
  • Gadgets continue to function.
  • Extensions deployed by the WMF should continue to function.
  • There shouldn’t be any negative performance impact from the new desktop experience.

The broad range of stakeholders, from our global community of editors and template/gadget/skin authors to teams at the Wikimedia foundation maintaining the hundreds of extensions currently deployed on Wikimedia sites, along with the technical limitations of the MediaWiki platform, make this a complex/chaotic problem space to consider.

Main question

Given the requirements and constraints mentioned above, the Readers Web team must decide the baseline upon which to implement such broad UI changes to the desktop interface of the Wikimedia projects. We are seeking input on this decision in order to uncover any concerns or alternative approaches that may have been overlooked or not thoroughly considered.


Proposals

When considering how to implement broad UI changes to the desktop versions of Wikimedia projects, the engineers on the Readers Web team considered the following options as possible foundations for the Desktop Improvements project. Each option has many pros and cons, but only the top three of each have been highlighted below.

Proposal 1: Adapt the MinervaNeue skin for desktop

Minerva is used as the foundation for the Desktop Improvements project. It becomes the default desktop skin for Wikimedia projects, replacing Vector. To meet the project requirement of incremental change, it will first become “vector-like” and gradually changes into whatever the new designs are from there on.

Pros

  • Already mobile optimized.
  • Brings us closer towards a unified skin for mobile and desktop.
  • Under active development by the Readers Web team.

Cons

  • Minvera depends heavily on the MobileFrontend extension.
  • Re-implements many core features such as sidebar and menus.
  • Would take considerable effort to achieve feature parity and visual parity with the current desktop experience.

Proposal 2: Add improvements inside the Vector skin

Vector remains the default skin on desktop and new improvements are made within the skin, with the current experience maintained in parallel. The new UI is feature-flagged and enabled on a per-component basis.

Pros

  • Changes could start being made without the startup cost of changing the default skin.
  • A feature flagging system could give the flexibility to enable/disable individual UI components.
  • Compatibility with Vector-specific code is maintained, such as Vector.js/css and hard-coded “vector” strings.

Cons

  • Requires developing a feature flagging system
  • Increased QA burden of ensuring we don’t break current Vector functionality.
  • A new user opt-in/out mechanism would have to be developed.

Proposal 3: Fork Vector and create a new skin

Vector is forked and a new skin is created. This new skin becomes the default for Wikimedia projects. Being a fork, it starts off as Vector but gradually changes as the Desktop Improvements project progresses.

Pros

  • Changes can be made without the risk of introducing regressions into an existing skin.
  • Maintains near parity with desktop features (save for code that checks for string “vector”).
  • Opt-in/out mechanism is straightforward (i.e. switching skins).

Cons

  • The technical complexity of deploying a new skin.
  • The maintenance cost for the development team of maintaining an additional skin.
  • The maintenance cost for the entire foundation of ensuring extensions work with an additional skin.
  • Potential lack of parity with extensions/gadgets that rely on the skin's key ('vector') which would not be present on the new skin

Proposal 4: Create a new skin based on Skin:Example that looks like Vector

Suggested by @Isarra we could

Pros

  • Using Skin:Example would remove a lot of Vector's technical baggage
  • Can be made to look like Vector
  • Opt-in/out mechanism is straightforward (i.e. switching skins).
  • Inherits only technical debt from mediawiki core.

Cons

  • Additional initial setup cost in tidying up HTML and CSS to mirror Vector
  • The technical complexity of deploying a new skin.
  • The maintenance cost for the development team of maintaining an additional skin.
  • The maintenance cost for the entire foundation of ensuring extensions work with an additional skin.
  • Potential risk to parity with Vector - The PHP code for the new skin would be different from Vector so there may be a lot of undocumented differences that need to be accounted for, before the skin becomes viable/usable.
  • Potential lack of parity with extensions/gadgets that rely on the skin's key ('vector') which would not be present on the new skin

Proposal 5:

Hypothesized by @Jdlrobson

If we want to build a new skin, but want to also improve Vector, we could build out a new skin inside the Vector repository.
Proof of concept: https://gerrit.wikimedia.org/r/545349

Pros

  • Possible to remove a lot of Vector's technical baggage gradually over time
  • Looks like (is) Vector from day one.
  • Opt-in/out mechanism is straightforward (i.e. switching skins).
  • Inherits only technical debt from mediawiki core.
  • Can be spun out into a new repository at a latter date
  • Refactors to the new skin's code also improve the Vector skin
  • No need to deploy a new skin.

Cons

  • Having a skin within a skin may be confusing and there is a risk that it will never be spun out
  • Potential lack of parity with extensions/gadgets that rely on the skin's key ('vector') which would not be present on the new skin
  • The maintenance cost for the entire foundation of ensuring extensions work with an additional skin could become more complicated over time.

Proposal 6


Initial Recommendation

After much deliberation the Readers Web team is proposing forking Vector and building a new skin for Wikimedia projects on desktop. Every solution has its pros and cons, but ultimately the ability to build upon an established foundation without the risk of introducing regressions into either the current desktop or mobile experience make forking Vector a practical yet promising baseline for the Desktop Improvements project.

The biggest argument against building a new skin may be the shortcomings of the current skin system itself. The responsibility of skins has not been clearly defined in MediaWiki, leading to unclear boundaries between skins and MediaWiki Core and extensions. However, by starting from a Vector fork we will be facing these problems head-on, and by addressing these issues at their core, we hope to make changes that will benefit the wider MediaWiki ecosystem wherever possible.


RFC Outcome

After even more deliberation, the Readers Web team will be going forward with building the Desktop improvements project inside the Vector skin. Many members of our technical community underscored the maintenance cost that a new skin (forked or not) would incur. Given this concern and the fact that we don’t plan on deprecating Vector in the foreseeable future, ensuring that Vector will benefit from any improvements we make was an important factor in this decision. Building the Desktop Improvements project inside Vector will ensure that this concern is addressed. It will also alleviate the startup & social costs of deploying a new skin. And although there are still maintenance costs in supporting the old experience alongside the new one, working inside Vector will make these changes readily available to all wikis, making bugs or regressions easier to catch as the new UI is being developed.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptOct 8 2019, 11:44 AM
Isarra added a subscriber: Isarra.Oct 8 2019, 2:08 PM

As always, I highly recommend against forking Vector. Its internals are dated and highly inconsistent after accumulated years of overengineering, and you will waste considerable time trying to clean that up/figure out what's going on, and even then you will undoubtably wind up with quite a bit of unnecessary code in your final product. Better to start from scratch: fork the Example skin, as recommended, and (re)add in the required features there. The result will be much cleaner, and ultimately easier to both make and maintain, following best practices.

And should you find anything that likely should have been in Example, as it should be available to and included in all skins, please submit updates there as well so others need not duplicate your efforts further.

Jdrewniak updated the task description. (Show Details)Oct 8 2019, 4:59 PM
nray added a subscriber: nray.Oct 8 2019, 11:38 PM
Bawolff added a subscriber: Bawolff.Oct 9 2019, 6:13 AM

The ability to differentiate a Wikimedia site (e.g. Wikipedia) from a third-party site running MediaWiki.

Just to confirm, by this you mean the new skin will not be the new default for mw and maybe not distributed with mediawiki, but still remain open source, right? (As opposed to say maintaining independent branding by making a closed source skin, which i would have a problem with)

The ability to differentiate a Wikimedia site (e.g. Wikipedia) from a third-party site running MediaWiki.

Just to confirm, by this you mean the new skin will not be the new default for mw and maybe not distributed with mediawiki, but still remain open source, right?

That's correct. The skin will be open source. By this requirement, we mean that we would like to establish a look and feel for the skin that is specific and most useful within Wikimedia projects. That said, if any third party finds it useful for their purposes, we wouldn't prevent them from using it in any way.

The ability to differentiate a Wikimedia site (e.g. Wikipedia) from a third-party site running MediaWiki.

Just to confirm, by this you mean the new skin will not be the new default for mw and maybe not distributed with mediawiki, but still remain open source, right?

That's correct. The skin will be open source. By this requirement, we mean that we would like to establish a look and feel for the skin that is specific and most useful within Wikimedia projects. That said, if any third party finds it useful for their purposes, we wouldn't prevent them from using it in any way.

Note that this was one of the objectives for Vector (with the intention to leave MediaWiki running MonoBook out of the box), and many third party users complained that their site "didn't look like Wikipedia", so it MediaWiki was changed to default to Vector. The differentiation may be hard to maintain if people are intentionally trying to look like you.

Volker_E updated the task description. (Show Details)Oct 9 2019, 6:22 PM
Krinkle moved this task from Inbox to Under discussion on the TechCom-RFC board.Oct 9 2019, 10:00 PM
stjn added a subscriber: stjn.EditedOct 9 2019, 10:07 PM

One other reason why Wikimedia-specific skin wouldn’t work is because WMF is still a (de facto) sole maintainer of MediaWiki software. If Wikimedia wikis move to a newer skin, unless there would be specific commitment from WMF to support the parity of MediaWiki skin and Wikimedia skin (what a naming!), the former would naturally become more and more dated and, thus, undesirable for end-users.

Though as someone who already redone Vector to be more Minerva-like for myself (see F30606154), I welcome the idea of newer look. I think forking Vector can inherit all its baggage (like it inherited Monobook’s), maybe a better goal would be to replicate it on a modern foundation and then do changes. Personally, I would like to see a day when our websites would look the same no matter the platform, though.

Krinkle renamed this task from New Skin for Desktop Improvements Project to RFC: Where to implement Desktop Improvements Project.Oct 10 2019, 5:16 PM
Krinkle renamed this task from RFC: Where to implement Desktop Improvements Project to RFC: Where to implement Desktop Improvements project.
Krinkle triaged this task as Normal priority.
Krinkle updated the task description. (Show Details)
Krinkle added a subscriber: Krinkle.EditedOct 10 2019, 5:19 PM

This new RFC was triaged in the TechCom triage meeting last Wednesday. It was found to have a clear problem statement and as such moved forward to "Under discussion". It also has several proposals already. I updated the structure to be more similar to other RFCs, making the sections easier to recognise for other participants.

Jdlrobson updated the task description. (Show Details)Oct 10 2019, 7:03 PM

I added a proposal 4 based on @Isarra's comment in T234907#5555593 for consideration.

Quiddity updated the task description. (Show Details)Oct 10 2019, 8:08 PM

I would strongly encourage you to make iterative improvements to Vector where possible. There is value in writing a new skin, yes, but a lot of what the Desktop Refresh project aims to achieve, especially more consistency between the desktop and mobile experiences, can be done with small iterative changes, so I suggest starting with that first.

As for larger changes, I would understand either writing a new skin or making significant changes to Vector (and I don't have a strong opinion at this point on which one of those two I like better), but I don't see why you'd fork Vector. It seems like the worst of both worlds. If you create a new skin, you get the benefit of being able to start over with a blank slate, at the cost of having to maintain one more skin. If you change Vector, you get the benefit of not having a bifurcated experience that users have to switch to, and the benefit of having existing tools (mostly) continuing to work, at the cost of having to deal with the existing code. If you fork Vector, you don't get the benefits either, and you pay the costs of both. You'll be a little bit freer to break existing things in a fork I suppose, but overall it would make more sense to me to either choose to make a clear break or to stick with Vector, not something in between.

I've shared it before – resolving several of the long-standing needs for changes to MediaWiki core's skinning system, see a.o. T114071: Let's discuss the skin creation process, would imply bringing those changes to both (Vector & new) skins. More so bringing it to all currently deployed Wikimedia skin. Even if we separate front-end architectural changes from product-inspired development efforts (f.e. new header appearance etc.), we wouldn't save a lot of work, rather have to invest more than iterating on existing skins.
Additionally to the partly unresolved maintenance question of current skins and future product developments, above leaves me to estimate that an iterative approach to Vector/MinervaNeue would provide a clear engineering cost advantage over an additional new skin mid- & long-term.

Thank you @Jdlrobson and @Isarra for the additional proposal of starting a new skin from scratch (and everyone who’s chimed in so far). During previous conversations with the web team, the option of a brand new skin was disregarded off-hand as being impractical. However, when considering the startup cost of fixing Vector vs. Building a Vector-like skin from scratch, I can see how the two might be comparable (having never written a skin myself though, it’s hard for me to judge).

The thinking behind forking Vector is that we would first refactor Vector in such a way that it could accommodate both the new and old designs. Architecting the skin in this way would allow us to slot in new UI elements on a per-component basis (e.g. new sidebar, header, etc.) instead of changing everything at once.

However, I see how this architecture could be achieved with all options (inside Vector, fork Vector, new skin).

I think it helps to look at some of the initial designs from the Wikimania slide deck when considering these options. https://www.mediawiki.org/w/index.php?title=File:Wikimania_-_desktop_improvements_session_final_version.pdf&page=28. I think it’s fairly certain that we will be making layout changes as part of this project.

We want the option to make these changes gradually, but I think it’s fair to say these changes will be big. If we make these changes inside Vector while maintaining the old Vector layout, to me that feels like we’d be making a skin inside a skin. We can refactor the layout inside Vector as well, but IMO, that risks breaking Vector everywhere in production. My primary rationale for advocating for a vector fork (or new skin) is the ability to make those changes without that risk.

Ladsgroup added a subscriber: Ladsgroup.EditedOct 16 2019, 2:23 PM

I think I understand the product reasoning behind the technical solution. If I understand the goal correctly. We need to provide two things to users: 1- Make gradual changes, no sudden or gradual roll out of a completely new look, so next month we start collapsing sidebar items, the month after that, moving them to up (just an example), and so on. 2- Let people get back to the old look if they don't like the changes. It makes sense to make a new skin by copy-pasting the vector code and calling it "Vector 2.0" and rolling it out to everyone, no one notice any changes, it's the same code. but then slowly moving things around in "Vector 2.0" to let people simply change to "vector" skin if they don't like the changes (at any stage).

I don't know how bad the code for Vector skin is but if it's not much code and the code is really bad, making a new skin that looks exactly the same makes sense (even replacing vector with the new code as well) but if it's lots of code and it's not that unmaintainable, forking makes more sense to me.

we (the Reader’s Web team) have been giving a lot more thought to the new-skin & update-vector proposals recently.

As @Volker_E mentioned, the foundation doesn’t have a good track-record of maintaining skins or deprecating old ones. This raises the possibility that in three years time, or whenever the Desktop Refresh project is “finished”, the new skin might start getting neglected and end up just like Vector. Working within Vector would avoid this scenario altogether.

I see the new-skin and update-vector options as working towards the same goal but from different ends, the goal being a foundation that enables us to gradually introduce UI changes.

In both scenarios, we would have to first clean up the skin system to better separate the data and the presentation layer. Then, for the vector-update scenario, we would have to refactor Vector to make the UI components easily replaceable. For the new-skin scenario, we would make the skin highly componentized from the ground up, but we would have to first make it look and function like Vector, in order to meet the requirement of gradually evolving it.

When the choice is framed as building a new skin that’s essentially a polished Vector clone vs. polishing Vector itself, then to me at least, the polishing-vector approach sounds like the more pragmatic of the two.

Jdlrobson added a comment.EditedTue, Oct 22, 5:34 PM

Thanks for all the comments so far ! Just to note, we are planning to make a decision by 31st October 2019. If you have any thoughts on the subject please do jot them down here before then so we make sure we have as much information going into that decision as possible.
Thanks in advance!

Edit: Note, I've added an additional proposal that came up in discussions today that is a variant of the forked Vector idea.

Jdlrobson updated the task description. (Show Details)Tue, Oct 22, 5:38 PM
Jdlrobson updated the task description. (Show Details)
Masumrezarock100 added a comment.EditedTue, Oct 22, 7:45 PM

Mind if I leave a comment or two here? I would pay need to @Isarra's suggestion. Vector is a unmaintained and complicated skin and as he said you will loose valuable time to figure out it's code and clean it up. Other proposals makes sense to me but I support the proposal one. Since Minerva is already optimized for mobile we won't need to work on it to improve mobile experience. True, Minerva does depend highly on MobileFrontend. But we'll have to break this dependency at some point per T171000. If you work on the proposal one you'll be passively working on the task too. We have several tasks here regarding Minerva third party support and you'll get a chance to work on those. My suggestion would be to leave fork or improve the desktop version of Minerva. Since it is currently under active development by Readers-web-team, I suppose they have more experience working with this skin than anyone else. Creating a new skin needs more effort, not to mention the maintenance costs. Phabricator would be flooded by new bug reports and tasks. You'll have to work extra to make the skin work better.

Thanks to all the feedback people have shared so far! It's been really helpful. If you are lurking on this ticket and also have thoughts, please do share them too!

In particular @TheDJ @Umherirrender @matmarex @Jdforrester-WMF @kaldari @ashley @Mooeypoo @Krinkle as people who have worked with the skin system or have worked on projects involving integrating with skins I would love some input from you here even if it's a simple "I don't think it matters" to help influence our decision before the 31st deadline. Thanks in advance!

Quiddity updated the task description. (Show Details)Wed, Oct 23, 5:22 PM
Milimetric updated the task description. (Show Details)Wed, Oct 23, 8:43 PM

Creating a new skin would be the default approach I'd take (whether by forking Vector or starting from scratch).

@matmarex Could you clarify further, why you would take that approach?

It sounds like you want to make fairly large changes, so that way sounds easier and less risky than adding special cases to an existing skin.

DLynch added a subscriber: DLynch.Tue, Oct 29, 12:28 AM

I want to second @Jdrewniak's point -- if we can refactor skins first so that skins really are a lighter presentation layer on top of a sensible base page structure, then whatever we choose for the rest of this doesn't matter so much. If we're not going to do that, there's a minefield ahead.

That said, assuming no major changes to how skins work...

Proposal 4 would be my pie-in-the-sky preference. It'd let us set a new baseline for things going forward, and clean off accumulated cruft. That's worth some pain, if we've got the political capital to see it happen and get adopted by the wikis.

Proposal 2 is my realistic choice. Incremental improvements within the existing Vector (maybe with Vector forked to a VectorClassic repo which we could push community maintenance of), which lets us slowly bring gadgets and extensions into compliance without any huge breaking changes, and hopefully avoiding any major community backlash.

I don't think we want to be in a situation where have to maintain more skins, especially no more skins with significant user bases. The amount of support we need to give each skin is proportional to the number of people using it. Accordingly monobook gets very little attention, but this is mostly accepted by the community. If we end up in a situation where VectorNew is the default for new users, but because it diverged too quickly, most of the experienced community is still using VectorClassic for gadget support or comfort, then this will translate into an increased developer burden.

I think the only way to avoid this would be to make small incremental changes to Vector, with appropriate deprecation/breaking change notices, so that the ecosystem can keep up (aka proposal 2).

stjn added a comment.Tue, Oct 29, 7:39 PM

There is no way to do what was, say, presented in those slides and not create a situation where a significant part of users will request to have VectorClassic no matter what, though.

Bawolff added a comment.EditedTue, Oct 29, 11:45 PM

I don't think we want to be in a situation where have to maintain more skins, especially no more skins with significant user bases. The amount of support we need to give each skin is proportional to the number of people using it. Accordingly monobook gets very little attention, but this is mostly accepted by the community. If we end up in a situation where VectorNew is the default for new users, but because it diverged too quickly, most of the experienced community is still using VectorClassic for gadget support or comfort, then this will translate into an increased developer burden.
I think the only way to avoid this would be to make small incremental changes to Vector, with appropriate deprecation/breaking change notices, so that the ecosystem can keep up (aka proposal 2).

Proposal 2 has a part "with the current experience maintained in parallel." I take it you're saying not to do that aspect?

Otherwise, with the maintain in parallel clause of that proposal left in tact, I feel like proposal 2 is just as much maintenance burden as any of the other proposals. (But I am not a skin person)


fwiw, my 2 cents is separate skin makes the most sense, perhaps with the two skins sharing some common code (via subclassing or whatever). It sounds like we're talking about making 2 separate skins anyways, but don't actually want to do that. However, pretending otherwise isn't going to magically change the fact we are making two separate skins, and might just make things more complicated in the long run. Thus I think the cleanest option is to call a spade a spade, and if we want to maintain two separate user experiances then make it actually be 2 separate things. That said, this isn't really the usual area I contribute to

@Bawolff thanks for your comment. I agree that in an ideal world, a new skin would be the most sensible option. However, given the state of the skinning system, extension compatibility, gadget compatibility, community buy-in, etc. I don't think the ecosystem is in a state where an additional skin is maintainable. As you mention, the "current experience maintained in parallel" line in Proposal 2 recognizes that realistically, we can't get rid of the current Vector "experience" anytime soon.

So if we’re not getting rid of it, we may as well try fixing it. This is the gist of Proposal 2 - making changes within Vector - and after long consideration, the web team has chosen to go forward with this approach.

@DLynch summarized the reasoning for this approach very well. It’s essentially the most pragmatic option as it avoids major breaking changes. Maybe as @Jdlrobson suggests, we’ll be able to eventually spin these changes out into a new skin in the future, but we wouldn’t want to do that until the skin system is in better shape.

Jdrewniak updated the task description. (Show Details)Fri, Nov 1, 3:52 PM

As @Jdlrobson mentioned earlier, the Web Team intended to make a decision on this by October 31 🎃.
I've updated the task description with our decision under the heading "RFC Outcome". Instead of forking Vector as originally proposed, we will be implementing the Desktop Improvements project inside Vector. Every option has it's trade-offs, and after considering the points made in this discussion, we felt that working in Vector was the most pragmatic way forward.
Thanks to everyone who contributed to this discussion!

I'd like to thank everyone who contributed to this discussion and commend the Web team on taking into consideration the tradeoffs. Looking forward to the results ahead.