Reading/Web/Desktop Improvements/Jon Robson's Hack Results

The reading web team spent a week doing research in preparation for the upcoming desktop improvements project.

We were tasked with implementing two side bar designs in Vector and Minerva. As I approached this activity, I wanted to focus on the question of "is there a world where we have the same skin for desktop and mobile?"

Minerva skin experiments

I began my experiments in the Minerva skin. It's been a longstanding request from editors to make the Minerva skin respect MediaWiki:Sidebar and be configurable so there was lots of background in a Phabricator ticket.

Minervas' menus differ from Vector's menus in three ways:

1. they contain user icons
2. They do not contain group headings - for example "help", "About interaction", "community portal", "recent changes" and "contact page" appear under a heading "Interaction"
3. the code is better organised - menus are better modelled in PHP - in that each menu and menu entry has an associated instance of a class.

To get the MediaWiki:Sidebar menu into Minerva, I realised that a refactors of core was necessary.

I refactored some large functions in core - an activity that was long overdue - and felt very valuable to expose the bits I needed.

Once these were done, integration in Minerva was relatively straightforward. I made a MediaWikiSidebarMenuBuilder to do the wire up. Due to the fact Minerva is structured, this side could be added to any part of the mobile interface - anonymous users, beta users or advanced mobile contributions users.

The next problem was adding the menu headings. This seemed like a useful activity for Minerva as it provided machine readable data associated with the headings. I updated the existing Minerva Group class to accept a heading label and hid it by default in Minerva. This allowed me to adjust my Minerva integration to display the headings.

With that done, I had the menu rendering in Minerva. If I'd done this for real rather than as an experimentation, I would have:

1. made editors and 3rd parties happy by squashing a much-requested bug
2. made the mobile site a little more readable to machines
3. cleaned up some code in core.

Vector

I then switched my attention to Vector. I created a feature flag in a similar way to the existing wgVectorResponsive and made it load an additional stylesheet when enabled.

With some minor changes to the template HTML (which I skipped sandboxing to the new feature flag) I adjusted the header of Vector. With CSS and template changes it was relatively easy to make Vector look like the mock.

The hamburger link proved a little more complicated. I felt compelled to use the existing makeCollapsible code but in the end I basic JavaScript script to make the menu collapsible.

The experiment here was pretty short. My conclusions were that it was easy enough to touch templates and CSS inside Vector, but anything involving JavaScript would be more difficult.

If I was to do this in production, I would link this up to the BetaFeatures extension. I think the challenge with a Vector approach would be ensuring that the current experience does not change (a requirement from product), however that felt like it may also keep us accountable to the goal, as any situations where we deviated from this goal would be flagged to us by editors almost immediately.

One challenge with taking the Vector approach however was the gulf between Minerva's mobile support and Vector's felt huge. Many of the reasons why Minerva is mobile friendly is that it has been able to change everything - HTML, CSS and JS. Having to keep Vector as it works against this goal. On top of this Vector ships almost 3 times the CSS and JS per page and would need a huge performance investment. For reference: Vector uses 229kb of JS and 18.4kb of CSS (AFTER GZIP); Minerva uses 63.2kb of JS, 8.4kb of CSS. Minerva DESKTOP uses 83kb of JS and 18.1kb of CSS (through no fault of it’s own). Clearly there is room for improvement here for Vector and Minerva. Our audience is growing in global south. We want them to load this new thing, right?

Vector also has a large group of maintainers outside the Wikimedia Foundation. I am interested to hear about their thoughts and goals and whether they match the idea of having a single skin.

Continued experiments

I became very interested in consolidating the Vector and Minerva experiences. I noticed how that Vector and Minerva were actually more similar than you might expect.

Minerva when run as a desktop skin, mostly has feature parity with Vector with a few exceptions - tables cannot be sorted and certain elements are not collapsible. For certain features, it runs its own bespoke version:

• it provides languages but not via the Universal Language Selector.
• It provides Echo notifications but not with the Vector modal - as a full screen overlay or slide out drawer.
• it provides its own logic for search
• it provides its own logic for watching articles

I found that I could consolidate the Minerva experience with Vector, by slight modifications to the logic that enabled code. For example I wrote a simple patch to integrate desktop Echo into Minerva and disabled certain features such as talk. I was tempted to go further and saw possible opportunities to improve the search/watch code inside core that powers Vector and use it in Minerva as well.

I was very easily with several interactions able to see a few changes that would make Minerva and Vector very aligned as the gif below shows.

I looked at doing the same in Vector, but found that the work necessary here was too great. I couldn't forsee myself making the Vector skin a better experience than Minerva's.

Conclusions

The team is considering 3 options for desktop improvements

1) Use Minerva

2) Use Vector

3) Use a new skin which begins as a fork of Vector

My opinion is that we need skin singularity in the long term - one skin for desktop and mobile and strategically (because of the fact such a skin needs to be mobile friendly) it needs to be Minerva!

I reflected on my experiments and the experiments that others have made. I think Timeless and Minerva skins both began as new skins with good intentions, but failed to change the bits of code in core that mattered. My impression is that many extension developers are tired of supporting all the skins we ship to users, as the skin system allows far too much flexibility and far too much that can go wrong. I felt strongly during this experience that a new skin (option 3) would be technical debt and run into many of the same issues as Timeless and Minerva as it would mean that Wikimedia would officially need to support 3 skins (Vector, Minerva and NewSkin). I was also a little worried about user gadget support, as most gadgets already work on Vector or Minerva and where they don't work on Minerva they do not throw errors and/or are explicitly disabled. A new skin would not have this guarantee.

I found the Minerva option favourable for several reasons:

1) it forced me to improve code in core while caring about mobile. If I had worked inside a new skin, I think I would optimise for avoiding upstream changes. If I worked in Vector, I would have optimised for not supporting mobile.

2) it led directly to user value. Every change I made seemed to be validated my a need to improve code or fix an open bug. For example, many of the overlay experiences on Minerva which work great for mobile do not feel so great on desktop. The idea of being able to make these work better for tablet, desktop users is very tempting.

3) It seemed like the only feasible option that seemed to lead to a single skin. I couldn't imagine ever making Vector as mobile friendly as Minerva given the time that it has taken to do that.

4) Changes to Minerva also benefit Vector. For instance performance improvements to Minerva-desktop skin would also benefit Vector given the shared nature of the codebase.

That said, I felt that the difference in user interface between Vector and Minerva was too great from a community point of view - switching the default skin from Vector to Minerva would be too much of a leap. To counteract this, my recommendation would be to make slight modifications to the Vector skin, with the goal of unifying it with Minerva in the future. A single skin would reduce the maintenance/building cost for all Wikimedia sites and would lead to improvements in the skin system that would hopefully benefit 3rd parties. Working on both skins, would allow us to work rapidly on subprojects alternating between skins, collecting feedback on one skin while working on the other. We would hear voices from desktop and mobile editors and make a skin that serves them both.

The two goals would be to:

1) Goal: make Vector's UI more Minerva-desktop-like

We'd need to put some feature flagging in place, but once that was done, I'd recommend focusing on HTML structure and menu organisation to unify the header and menu designs (and contents) of Vector with Minerva. I think there would be longer feedback cycles in this approach but more eyes - as editors actually use Vector! We'd avoid adding any JavaScript to the experience as I don't think this adds much value and is worth the investment given the alternatives in Minerva.

2) Goal: Make desktop Minerva more Vector like

The focus here would be functionality - feature equivalence. Unlike Vector, Minerva already has the necessary feature flagging so it would be easier to get up and running quicker. The AMC mode already runs in desktop and I would recommend working within this mode for the desktop improvements audience. Stage 1 would involve getting Minerva to respect MediaWiki:Sidebar: That’s all editors really want. This means that their gadgets can add to it and we would refactor some nasty code in core in the process. A second interaction would fill in the missing features (benefiting mobile too) to add the much requested sortable tables and collapsing features to mobile AND desktop.

With these 2 goals completed, I'd hope that Minerva and Vector would be seen on equal par, and Minerva could be accepted as the default desktop and mobile skin. The new experience would be mobile friendly, feature-rich and performant and within brand.

Question: How do we know when we are done?

Answer: Side by side on a desktop browser I can’t tell if I’m looking at Vector or Minerva.

Open questions

• Do we want to maintain a separate desktop and mobile skin?
• We need to evaluate everywhere mobile has forked desktop and scrutinise whether it’s worth it
  • Do we need to maintain a completely different Echo notifications experience for example? How can we bend things so that we don’t have to do that?
  • Do we need a talk overlay on desktop? Could we just link?
  • Do we need custom search and watchstar code? Could we use the same for Vector and Minerva?
  • Why are the fonts/colors different?
  • Do we need a seperate beta mode for anonymous users on mobile or could we use Extension:BetaFeatures
• Is improving desktop performance in scope?
  • The code loaded on desktop is crazy. Let’s work with performance team to bring that down for all skins.
  • When Minerva runs on the desktop domain it runs over double the code it does on the mobile domain with more-or-less the same result.